Opened on 03/26/2019 at 08:12:49 AM

Closed on 08/29/2019 at 05:43:52 PM

#7404 closed change (rejected)

Add GitLab merge request template to adblockpluscore repo

Reported by: mjethani Assignee: mjethani
Priority: P3 Milestone:
Module: Core Keywords: closed-in-favor-of-gitlab
Cc: sebastian, wspee Blocked By:
Blocking: Platform: Unknown / Cross platform
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description

Background

Since we have started doing code reviews on GitLab, it makes sense to have at least one default merge request template.

See the GitLab documentation for description templates.

What to change

Add a file .gitlab/merge_request_templates/default.md to the repo with an appropriate template.

Attachments (0)

Change History (7)

comment:1 Changed on 03/26/2019 at 08:13:59 AM by mjethani

  • Owner set to mjethani

comment:2 follow-up: Changed on 03/28/2019 at 07:01:48 PM by sebastian

  • Cc sebastian wspee added

I'm curious what you would put into a merge request template?

comment:3 in reply to: ↑ 2 Changed on 04/11/2019 at 09:32:59 AM by mjethani

Replying to sebastian:

I'm curious what you would put into a merge request template?

Frankly I have been struggling with it and at this point I think maybe it's even a good idea to let it evolve.

comment:4 follow-up: Changed on 04/11/2019 at 09:33:14 AM by mjethani

Anyway, since you asked, the initial template I wrote had this:

  • List of issues affected
  • Description: What you have changed, what the original problem is, how you are addressing it in your patch, and so on
  • Checklist: At a minimum, your patch must address the issue(s), pass all tests, and pass linting; beyond this, it should update any related documentation and tests, and it should work with adblockpluschrome; if it does not work out of the box with adblockpluschrome, please explain how you broke compatibility and what adblockpluschrome or any of its dependencies can do to catch up; if your patch affects performance (memory or CPU usage), please explain how
  • How important is this patch to you personally? (e.g. the changes would be very valuable for the next release, which is going into code freeze soon, and you are off on vacation in a few days; in that case, please say "High" priority so the reviewers know to look at this first; but also do not abuse this)

At some point I thought that it was a bit overdone and I left it.

Nevertheless, I have started doing something like this for my patch submissions (e.g. !43, !45, !47, !48, !51).

I think we should try different ideas and let it evolve.

comment:5 in reply to: ↑ 4 Changed on 04/11/2019 at 09:38:49 AM by mjethani

Replying to mjethani:

  • Description: What you have changed, what the original problem is, how you are addressing it in your patch, and so on

This, by the way, is inspired by the commit messages for my Chromium changes. I would briefly describe the issue at a technical level and what the patch did to address it. e.g. https://crrev.com/c/913628 (review) and https://crrev.com/538722 (commit).

comment:6 Changed on 04/11/2019 at 07:13:49 PM by sebastian

Thanks for sharing. However, most of these information seem redundant to me. The issues addressed should be referenced in the commit message / merge request title, information about the change itself should rather go into the issue description (maybe except for some optional low level explanations), and making sure that tests and linting passes is done through the CI.

Also I doubt that prioritization through the merge request description will work. I mostly work through my inbox like a TODO list. When I get to the notification email of the merge request, I will review it, but I won't read the merge request description any earlier. When I have some backlog and there is an urgent merge request you might have to ping me on IRC, and I'm used to do the same when I feel that a merge request that I created isn't getting enough attention. The exception might be huge patches that take me several hours to review, but I won't get around to review the merge request any sooner just because someone requested a priority review either in that case.

Last edited on 04/11/2019 at 08:41:01 PM by sebastian

comment:7 Changed on 08/29/2019 at 05:43:52 PM by sebastian

  • Keywords closed-in-favor-of-gitlab added
  • Resolution set to rejected
  • Status changed from new to closed

Sorry, but we switched to GitLab. If this issue is still relevant, please file it again in the new issue tracker.

Add Comment

Modify Ticket

Change Properties
Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from mjethani.
 
Note: See TracTickets for help on using tickets.