[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] Use GitLab Milestones
From: |
Jonas Hahnfeld |
Subject: |
Re: [RFC] Use GitLab Milestones |
Date: |
Tue, 23 Jun 2020 10:40:34 +0200 |
User-agent: |
Evolution 3.36.3 |
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
Re: [RFC] Use GitLab Milestones, Valentin Villenave, 2020/06/23
- Re: [RFC] Use GitLab Milestones, Jonas Hahnfeld, 2020/06/23
- Re: [RFC] Use GitLab Milestones, Jean Abou Samra, 2020/06/23
- Re: [RFC] Use GitLab Milestones, Jonas Hahnfeld, 2020/06/23
- Re: [RFC] Use GitLab Milestones, Carl Sorensen, 2020/06/23
- Re: [RFC] Use GitLab Milestones, Jonas Hahnfeld, 2020/06/23
- Re: [RFC] Use GitLab Milestones, Carl Sorensen, 2020/06/23