[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: Wed, 24 Jun 2020 12:41:42 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0


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

Those milestones are closed after we verified all issues for a given

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.


reply via email to

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