Re: [RFC] Use GitLab Milestones

[Jonas Hahnfeld]

Am Dienstag, den 23.06.2020, 20:54 +0200 schrieb 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.

"carefully ensuring" means going through all labels. Whether we just
delete them once verified or defer that to a script shouldn't make much
of a difference. Except that we don't need a script.

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

clarification: for me >as a developer<

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

Yes, I was also referring to that. And again, I don't think there's a
change in action here except for replacing the labels by milestones.

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

, and add it to a milestone. This makes it easier for the community to
see what's part of the release and corresponds to what we've been doing
so far.

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

This won't work because there will be many issues without a milestone.
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.


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

Never understood the difference between Started and Accepted either.
But removing them requires a bit more thought than that.

Jonas

> 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

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