Hi,
intrigeri (2020-06-03):
> Cyril Brulebois (2020-06-01):
>> I'll share some more, spotted during the last few days and while
>> finalizing the contents of 4.7 thanks to anonym's help:
>>
>> * It would be nice if we could close tickets from a commit message,
>> e.g. when merging a branch, as we used to be able to with “Closes:
>> #N”. It might not be important on the long run if we standardize for
>> always using a MR, but I'd be happy not to have to remember closing
>> tickets manually while we deal with the many topic branches we have.
>> Various attempts seems to have failed (d4ffd3ebc60c, 7f5361119001).
>>
>> * One might think “just use a MR” as a reply to the aforementioned
>> point but right now, I'm not convinced… The commit message doesn't
>> mention bug(s) getting fixed, doesn't contain a direct link to the
>> MR, and just a reference the interested reader needs to resolve on
>> their own. Of course, for single-bug topic branches, the name might
>> be sufficient. For longer-lived branches (overlayfs, secure boot,
>> etc.), I'm pretty sure all bugs won't be mentioned in the branch's
>> name.
>
> I hear you and I personally find these problems annoying as well.
> To sum up what I see:
>
> - Regarding "mention all relevant issues in the commit message", one
> workaround is to do what we would have done pre-GitLab, that is:
> manually edit the merge commit message to include the desired info
> (be it via the GitLab web UI or by merging locally).
> But of course it would be better to automate this!
>
> - We do have a regression wrt. closing issues while merging,
> compared to Redmine.
>
> I've looked deeper into this topic a couple days ago after our
> conversation on XMPP, and here's what I found:
>
> 1. The "close referenced issues when merging" behavior only works
> for the main branch, i.e. currently "master" in our case.
>
> One lead I'd like to investigate is making "devel" our main branch
> (and in passing, perhaps rename "master" to "website"). I did not
> verify what would happen under that config in the most common
> scenarios, that is when the target branch of the MR is stable, and
> then one merges stable manually into devel.
> [...]
> All this seems to boil down to GitLab being optimized for
> 1-main-branch workflows. I'd like to spend some time thinking about
> how we could adjust our workflow to fit better. I'll focus on the
> regression (closing issues via merge commits) to start with.
I've looked into this a bit closer and I'm afraid my initial idea
(making "devel" our default branch) won't work in the most common
scenario: the target branch of the MR is stable, and then one merges
stable manually into devel.
So, I propose we make "stable" our default branch for the tails/tails
GitLab project.
This basically moves the problem this sub-thread is about from
"code" developers to tech writers & website developers:
(+) When merging a MR targeted at "stable", issues referenced with
"Closes" in its description will automatically be closed.
This addresses the main problem raised by kibi.
It also encourages developers to properly use "Closes" in MR
descriptions, which in turn yields more useful auto-generated
merge commits; this will be a must anyway when we start
auto-generating our changelog from closed MRs & issues.
(+) Developers don't have to manually set the target branch of
their MRs to "stable" anymore.
(-) After merging a MR into master or devel, one will need to
manually close issues.
Currently this mostly affects sajolida in practice, since
other tech writers and website developers cannot merge MRs,
and it's rare that a MR targets devel rather than stable.
I see that sajolida generally merges branches manually instead
of using the "Merge" button, so he's not taking advantage of
the "Auto-close referenced issues" feature, so I understand
losing it won't be a regression for him in practice.
(-) Tech writers and website developers have to manually set the
target branch of their MRs to "master".
If they forget, then:
- The reviewer can fix this mistake on the MR before clicking
the "Merge" button.
- If sajolida merges manually into "master", then the MR will
remain open, which provides an indication that something is
wrong. Then someone will need to merge "master" into
"stable".
- If we merge by clicking the "Merge" button, the changes won't
go live on our website immediately.
- Worst case, the merged MR will go live when the next release
is published.
That's not great, but perhaps not a blocker, i.e. we could try
and see how it fares in practice?
What do you think?
To me the advantages outweigh the drawbacks.
Any other pros or cons?
Thoughts?
