Re: [RFC] Use GitLab Milestones

[Jean Abou Samra]

Hi,

Le 23/06/2020 à 17:50, Jonas Hahnfeld a écrit :
> Am Dienstag, den 23.06.2020, 15:54 +0200 schrieb Valentin Villenave:
> > On 6/22/20, Jonas Hahnfeld <hahnjo@hahnjo.de> 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. 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.
> > > […]
> > > 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 😉

Of course. It's a very nice idea.

Are we really going to delete all Fixed_X_Y_Z labels by hand though?
I believe that a second script could help achieve that, after we carefully
ensured that the first script setting milestones worked correctly.

> > Sounds good.  I only have a few questions:
> >
> > - How do you plan to indicate backports? (Granted, this is a very
> > limited subset.)
> Yes, that's the question for the 277 issues with at least two labels.
> I'd argue that we're interested in the first released version. So maybe
> just removing the unstable release?
Sounds reasonable. That was Trevor's opinion too, if I remember well
(I don't have time to search the archives, though, but I recall it has
been discussed already).
> > - What would become the process of marking issues as Fixed/Verified?
> > At what stage do we “close” them? (I’d like to make sure that anything
> > that has been fixed on master will be double-checked once the next GUB
> > release is out; marking the milestone as “closed” wouldn’t offer much
> > granularity in that regard, would it?)
> >
> > - By the way if I understand you correctly, the milestone would be
> > “closed” _prior_ to the release? Then how do we validate bugfixes?
> I think we're in confusion here: Closing a milestone does nothing to
> its issues. You just can't assign new issues to the milestone and it
> won't show up in the dropdown. So I think there's no change to issue
> verification, which for me currently means: close the issue, set
> Status::Fixed and the version it was fixed in (a milestone). After all
> issues have been assigned, we can close the milestone (probably some
> days after the version has been released).
I guess you're not on the same wavelength here. My understanding is that
by "validating bugfixes" Valentin means the process outlined in
http://lilypond.org/doc/v2.19/Documentation/contributor/bug-squad-checklists 
,
that is, what has recently be done thanks to a crowd-sourced effort: check
that every bug claimed fixed was actually fixed in the latest GUB 
release before
marking the issue as "Status::Verified" instead of "Status::Fixed". For
patch-tracking issues, it used to be verified that a commit with the
right SHA was indeed present in master. Since there isn't any risk with
merge requests, I think this part is no longer relevant (while previously
someone could have closed the issue while forgetting to push the commit).

Whether we want to continue to verify issues this way is another question.
Assuming we do, here is how I would envision the process on GitLab:

- When a merge request adressing an issue is merged, the issue should be 
closed.
Verifying issues is done as a precaution, so issues should no longer 
appear on
our dashboard once they have been addressed by a merge request. It is 
convenient
to set the merge request to close the issue automatically upon merge.

- 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.

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.

Actually, I think the while Status family of scoped labels will no longer
need to exist. Status::Fixed and Status::Verified are replaced as above.
In addition, assigning issues should replace Status::Started (this provides
an additional piece information, the person who started working). 
Status::Duplicate
and Status::Invalid should be moved to Type (we already have a 
Type::Invalid). One
remaining question is about the difference between Status::New and 
Status::Accepted.
I don't really know what should be done about it.

Dan is entirely right: some scoped labels should become non-scoped to make
coexistence possible.

Newbie here. Is that the kind of answer you expected?

Best,
Jean