Re: [RFC] Use GitLab Milestones

[Jonas Hahnfeld]

Hi James,

Am Dienstag, den 23.06.2020, 08:00 +0100 schrieb James:
> Hello
> 
> On 22/06/2020 18:33, Jonas Hahnfeld wrote:
> > In short, I'd like to propose that we replace the labels Fixed_x_y_z
> > with milestones x.y.z and use these to track which issues were fixed
> > for a particular release.
> 
> Just so you know I have just gone through all the 'Fixed_' labels this 
> morning and they are all consistent now.
> 
> The form is
> 
> Fixed_X_XX_XX
> 
> e.g Fixed _2_04_01 or Fixed_2_19_01
> 
> There was no consistency for single digit or version 'zero' builds so I 
> made sure they always had 2 numerals even they were '00' just in case 
> this helps with find/replace.

Okay, didn't notice that one. Do we want to retain this? Right now, I'm
parsing integer numbers, so the milestones would be "2.4.1" and
"2.19.1" for the two examples above. I think this matches what the
releases advertise themselves, but not sure.


> > [...]
> > 
> > The bad news is that both creating and assigning a milestone induce
> > notifications. We likely don't want to receive 4000 emails when running
> > the scripts, so we should disable notifications of the lilypond project
> > for that time frame. This means contributions during that period (~30
> > minutes?) might stay under the radar at first, but that's probably
> > acceptable.
> That's a good idea. Perhaps block all access for that period (can you do 
> that easily and informatively?).

I fear I can't for external contributors, at least not without possibly
breaking a bunch of stuff:
 * Making the whole repo private might disassociate forks.
 * Not sure what happens to existing MRs if I disable them for the
repo. Plus issues have to stay active, that's the point of running the
scripts.

However, I think disabling notifications leaves the activity stream
working (see https://gitlab.com/lilypond/lilypond/activity) and this
will only show entries when creating the milestones, ie not when
assigning issues. Skipping ~330 entries sounds feasible for checking
that nothing was lost, plus you can filter for "Issue events" (new
issues) and "Comments". So the whole topic is less bad than I initially
thought.

> > Let me know what you think!
> 
> There is one thing that I find with the labels (and I don't care either 
> way) its those of the form
> 
> Type::XXX vs just a normal string
> 
> e.g. Type::Maintainabilty vs just Maintainability.
> 
> You cannot have two labels of Type::XXX on the same issue. So an issue 
> that was labelled 'Font' AND 'Scripts' in the past, for instance, could 
> not be both Type::Font AND Type::Scripts. One replaces the other (at 
> least when I tested it manually).

Not exactly related to this one, but I think there was at most one
'Type' on SourceForge as well, so scoped labels looked like the
corresponding thing on GitLab.

> Is this XXX:: what they call 'scoping'? Anyway, we're a few 'non-scoped' 
> labels out there and I wonder (apart from the 'Patch::' labels) what the 
> pros and cons of having a XXX:: label vs just a string.

Pretty much that: You can only have one label from the same scope, and
assigning a second automatically removes the old (cf. Patch::*). I
actually agree that multiple Type's might be useful. If others are in
favor as well, we can just rename the labels.

Jonas

> 
> James

signature.asc
Description: This is a digitally signed message part