[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Use GitLab Milestones

From: Jean Abou Samra
Subject: Re: [RFC] Use GitLab Milestones
Date: Tue, 23 Jun 2020 20:54:20 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]