Re: [RFC] Use GitLab Milestones

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

> > > 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<
Ah, got it this time. Sorry.
> > > 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'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

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

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.

Best,
Jean