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