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