Re: [RFC] Use GitLab Milestones

[Jonas Hahnfeld]

Am Mittwoch, den 24.06.2020, 12:41 +0200 schrieb Jean Abou Samra:
> Hi,
> 
> Le 23/06/2020 à 21:47, Jonas Hahnfeld a écrit :
> > "carefully ensuring" means going through all labels.
> 
> Does it? I thought we'd just verify it carefully for a handful
> of them, including corner cases.

I think it should mean that because the operation is destructive. The
logic of the scripts might be relatively sound, but you never know what
will be the corner cases before you notice them.

> > > - When an unstable release is out, we browse all closed issues that do
> > > not have a
> > > milestone, like with
> > > https://gitlab.com/lilypond/lilypond/-/issues?scope=all&state=closed&milestone_title=None
> > > 
> > > We compile the minimal example given on the tracker page. The bug should 
> > > be
> > > solved (or the enhancement should be visible), so when we've made sure of
> > > that, we put a milestone on the corresponding issue.
> > 
> > This won't work because there will be many issues without a milestone.
> 
> I'm likely being dense here, but I don't understand. The amount of 
> closed issues
> without a milestone would be exactly the amount of issues that need 
> verification,
> wouldn't it? Granted, there are also invalid issues, so the URL should 
> have been
> https://gitlab.com/lilypond/lilypond/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=None&not[label_name][]=Status%3A%3AInvalid&not[label_name][]=Type%3A%3AInvalid

As you can see already from the first page, there are many issues
without information when the problem was fixed. I don't want to go
through all of them in order to make the procedure work.

> > I think it makes more sense to set the milestone when closing the issue
> > (see above) and afterwards search for issues in Status::Fixed. Again,
> > no change from the current procedure except for adapting the technical
> > implementation.
> > 
> > > Those milestones are closed after we verified all issues for a given
> > > release.
> > > 
> > > This obviates the need for the series of labels Status::Fixed, Fixed_X_Y_Z
> > > and Status::Verified, which tends to make things simpler. The new way of
> > > saying Status::Fixed is to close the issue. The way of stating an issue
> > > was verified is to give it a milestone indicating the first release it was
> > > fixed in.
> > 
> > I'm against doing this. Otherwise we won't be able to differentiate
> > between an issue being, say, invalid and fixed.
> 
> Again, please enlighten my foolishness. I was just proposing to label 
> invalid
> issues with Type::Invalid instead of Status::Invalid; I don't understand how
> that prevents from differentiating between invalid and fixed.

I was referring to "The new way of saying Status::Fixed is to close the
issue".

> That said, a label Status::Fixed instead of the absence of a label is 
> more explicit,
> which is perhaps a better option. Although I still think Status::Invalid 
> and Type::Invalid
> should be merged either way.

Seems simple enough to do, there are only 2 issues with Type::Invalid.

Jonas

> Best,
> Jean

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