[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Use GitLab Milestones

From: James
Subject: Re: [RFC] Use GitLab Milestones
Date: Tue, 23 Jun 2020 08:00:12 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0


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


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.

This has the advantage of a) less labels
which makes the drop-downs more usable and b) the possibility to close
milestones. After all, we're not going to fix bugs in already released
versions and they don't need to be available for new issues.

This topic already surfaced right after the migration to GitLab, but
now I finally had the chance to look into this with more detail. In
particular we now seem to have a common naming for the labels in
question (great work by James!) which makes scripting much more

I've already started to write scripts to create the 328 milestones
(that's what they tell me) and automatically assign 3662 issues which
have exactly one label of the form mentioned above. Additionally, my
scripts think that there are 277 issues with two or more labels
(attached to this message). Most are instances of "fix was backported
to a stable version", but I'd like to check them manually. Also
deleting the labels stays manual to make sure that the scripts
correctly assigned the milestones and did not miss any. Help on this
part would be appreciated after running the scripts 😉

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
That's a good idea. Perhaps block all access for that period (can you do that easily and informatively?).
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).

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]