Re: [RFC] Use GitLab Milestones
Am Dienstag, den 30.06.2020, 14:54 +0200 schrieb Jonas Hahnfeld: > Am Montag, den 29.06.2020, 08:25 -0400 schrieb Dan Eble: > > On Jun 29, 2020, at 07:49, Jonas Hahnfeld wrote: > > > I got the list down to five corner cases, all involving multiple > > > commits related to a single issue. > > > > ... > > > I think it would be sufficient to have the final release that included > > > all commits, but wanted to check back if everybody agrees on that. > > > > Sounds reasonable to me. > > Great. I'll go ahead with creating and assigning the milestones > tomorrow morning. I think this went fine overall and we now have 321 milestones. As far as I can tell, disabling the notifications worked as intended and there was not activity except for my scripts running. If I still overlooked something you did since 9:00 (CEST), you might want to ping it because it might get lost otherwise. The next step will be to go trough all labels Fixed_x_y_z and verify that the issues now have the correct milestone set, ie open the list of closed issues for that label (for example https://gitlab.com/lilypond/lilypond/-/issues?scope=all=%E2%9C%93=closed_name[]=Fixed_2_19_84 ) and check a) that label and milestone match, and b) there's indeed no other label that my scripts overlooked. Afterwards, just delete the label (no need to remove it from the issues first). If you want to help: I'll start with the oldest versions. One nice thing of milestones that I learned about yesterday is the overview of all associated labels: https://gitlab.com/lilypond/lilypond/-/milestones/320#tab-labels That also gives a direct link to all issues with Status::Fixed that need verification Cheers Jonas signature.asc Description: This is a digitally signed message part
Re: [RFC] Use GitLab Milestones
Am Montag, den 29.06.2020, 08:25 -0400 schrieb Dan Eble: > On Jun 29, 2020, at 07:49, Jonas Hahnfeld wrote: > > I got the list down to five corner cases, all involving multiple > > commits related to a single issue. > > ... > > I think it would be sufficient to have the final release that included > > all commits, but wanted to check back if everybody agrees on that. > > Sounds reasonable to me. Great. I'll go ahead with creating and assigning the milestones tomorrow morning. Regards Jonas signature.asc Description: This is a digitally signed message part
Re: [RFC] Use GitLab Milestones
On Jun 29, 2020, at 07:49, Jonas Hahnfeld wrote: > > I got the list down to five corner cases, all involving multiple > commits related to a single issue. ... > I think it would be sufficient to have the final release that included > all commits, but wanted to check back if everybody agrees on that. Sounds reasonable to me. — Dan
Re: [RFC] Use GitLab Milestones
Am Freitag, den 26.06.2020, 11:35 +0200 schrieb Jonas Hahnfeld: > Am Mittwoch, den 24.06.2020, 13:29 +0200 schrieb Jonas Hahnfeld: > > Am Dienstag, den 23.06.2020, 20:54 +0200 schrieb Jean Abou Samra: > > > Le 23/06/2020 à 17:50, Jonas Hahnfeld a écrit : > > > > Am Dienstag, den 23.06.2020, 15:54 +0200 schrieb Valentin Villenave: > > > > > - 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). > > > > Yes, see: > > https://lists.gnu.org/archive/html/lilypond-devel/2020-05/msg00323.html > > > > > > Actually, it might be a good idea to deal with these issues before > > running the script, so all (initial) milestones can be assigned > > automatically. Ok for everyone? > > I'll start working on these issues from the top (see list). If you want > to help, maybe start at the bottom or somewhere in the middle. I got the list down to five corner cases, all involving multiple commits related to a single issue. https://gitlab.com/lilypond/lilypond/-/issues/154 https://gitlab.com/lilypond/lilypond/-/issues/1861 These two issues saw additional fixes after several years. https://gitlab.com/lilypond/lilypond/-/issues/3807 https://gitlab.com/lilypond/lilypond/-/issues/4062 https://gitlab.com/lilypond/lilypond/-/issues/5039 Similar, but just multiple patches spread over subsequent releases. I think it would be sufficient to have the final release that included all commits, but wanted to check back if everybody agrees on that. Jonas signature.asc Description: This is a digitally signed message part
Re: [RFC] Use GitLab Milestones
Am Mittwoch, den 24.06.2020, 13:29 +0200 schrieb Jonas Hahnfeld: > Am Dienstag, den 23.06.2020, 20:54 +0200 schrieb Jean Abou Samra: > > Le 23/06/2020 à 17:50, Jonas Hahnfeld a écrit : > > > Am Dienstag, den 23.06.2020, 15:54 +0200 schrieb Valentin Villenave: > > > > - 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). > > Yes, see: > https://lists.gnu.org/archive/html/lilypond-devel/2020-05/msg00323.html > > Actually, it might be a good idea to deal with these issues before > running the script, so all (initial) milestones can be assigned > automatically. Ok for everyone? I'll start working on these issues from the top (see list). If you want to help, maybe start at the bottom or somewhere in the middle. Regards Jonas https://gitlab.com/lilypond/lilypond/-/issues/7 has two labels https://gitlab.com/lilypond/lilypond/-/issues/20 has two labels https://gitlab.com/lilypond/lilypond/-/issues/53 has two labels https://gitlab.com/lilypond/lilypond/-/issues/56 has two labels https://gitlab.com/lilypond/lilypond/-/issues/57 has two labels https://gitlab.com/lilypond/lilypond/-/issues/58 has two labels https://gitlab.com/lilypond/lilypond/-/issues/74 has two labels https://gitlab.com/lilypond/lilypond/-/issues/75 has two labels https://gitlab.com/lilypond/lilypond/-/issues/85 has two labels https://gitlab.com/lilypond/lilypond/-/issues/86 has two labels https://gitlab.com/lilypond/lilypond/-/issues/87 has two labels https://gitlab.com/lilypond/lilypond/-/issues/93 has two labels https://gitlab.com/lilypond/lilypond/-/issues/94 has two labels https://gitlab.com/lilypond/lilypond/-/issues/104 has two labels https://gitlab.com/lilypond/lilypond/-/issues/106 has two labels https://gitlab.com/lilypond/lilypond/-/issues/122 has two labels https://gitlab.com/lilypond/lilypond/-/issues/129 has two labels https://gitlab.com/lilypond/lilypond/-/issues/136 has two labels https://gitlab.com/lilypond/lilypond/-/issues/149 has two labels https://gitlab.com/lilypond/lilypond/-/issues/152 has two labels https://gitlab.com/lilypond/lilypond/-/issues/154 has two labels https://gitlab.com/lilypond/lilypond/-/issues/156 has two labels https://gitlab.com/lilypond/lilypond/-/issues/159 has two labels https://gitlab.com/lilypond/lilypond/-/issues/164 has two labels https://gitlab.com/lilypond/lilypond/-/issues/165 has two labels https://gitlab.com/lilypond/lilypond/-/issues/166 has two labels https://gitlab.com/lilypond/lilypond/-/issues/167 has two labels https://gitlab.com/lilypond/lilypond/-/issues/168 has two labels https://gitlab.com/lilypond/lilypond/-/issues/170 has two labels https://gitlab.com/lilypond/lilypond/-/issues/172 has two labels https://gitlab.com/lilypond/lilypond/-/issues/173 has two labels https://gitlab.com/lilypond/lilypond/-/issues/174 has two labels https://gitlab.com/lilypond/lilypond/-/issues/175 has two labels https://gitlab.com/lilypond/lilypond/-/issues/177 has two labels https://gitlab.com/lilypond/lilypond/-/issues/178 has two labels https://gitlab.com/lilypond/lilypond/-/issues/180 has two labels https://gitlab.com/lilypond/lilypond/-/issues/182 has two labels https://gitlab.com/lilypond/lilypond/-/issues/183 has two labels https://gitlab.com/lilypond/lilypond/-/issues/184 has two labels https://gitlab.com/lilypond/lilypond/-/issues/190 has two labels https://gitlab.com/lilypond/lilypond/-/issues/192 has two labels https://gitlab.com/lilypond/lilypond/-/issues/193 has two labels https://gitlab.com/lilypond/lilypond/-/issues/194 has two labels https://gitlab.com/lilypond/lilypond/-/issues/195 has two labels https://gitlab.com/lilypond/lilypond/-/issues/199 has two labels https://gitlab.com/lilypond/lilypond/-/issues/200 has two labels https://gitlab.com/lilypond/lilypond/-/issues/201 has two labels https://gitlab.com/lilypond/lilypond/-/issues/203 has two labels https://gitlab.com/lilypond/lilypond/-/issues/207 has two labels https://gitlab.com/lilypond/lilypond/-/issues/208 has two labels https://gitlab.com/lilypond/lilypond/-/issues/210 has two labels https://gitlab.com/lilypond/lilypond/-/issues/211 has two labels https://gitlab.com/lilypond/lilypond/-/issues/214 has two labels https://gitlab.com/lilypond/lilypond/-/issues/219 has two labels https://gitlab.com/lilypond/lilypond/-/issues/221 has two labels https://gitlab.com/lilypond/lilypond/-/issues/222 has two labels https://gitlab.com/lilypond/lilypond/-/issues/224 has two labels https://gitlab.com/lilypond/lilypond/-/issues/225 has two labels https://gitlab.com/lilypond/lilypond/-/issues/226 has two labels
Re: scoped labels (was: Re: [RFC] Use GitLab Milestones)
Am Mittwoch, den 24.06.2020, 13:23 +0200 schrieb Jonas Hahnfeld: > Am Dienstag, den 23.06.2020, 13:04 -0400 schrieb Dan Eble: > > On Jun 23, 2020, at 04:40, Jonas Hahnfeld wrote: > > > Pretty much that: You can only have one label from the same scope, and > > > assigning a second automatically removes the old (cf. Patch::*). I > > > actually agree that multiple Type's might be useful. If others are in > > > favor as well, we can just rename the labels. > > > > My default position is to avoid restrictions when there isn't a good reason > > for them. There are some types in the current set that I can't imagine > > using together – for example (Enhancement|Maintainability) with > > (Crash|Defect|Regression) – but unless that endangers the efficiency of > > someone's workflow, I don't think we should spend time compartmentalizing > > them. > > > > Patch::* obviously need to remain scoped because they name states in a > > state machine. > > I think there's agreement that: > * Type::* should be made plain labels. > * Patch::* must stay scoped. > > I can do the renaming of Type::* if nobody objects. Done. Type::Invalid is gone because the two issues already had Status::Invalid, and Defect and Type::Defect have been merged. Jonas signature.asc Description: This is a digitally signed message part
Re: [RFC] Use GitLab Milestones
Am Dienstag, den 23.06.2020, 20:54 +0200 schrieb Jean Abou Samra: > Le 23/06/2020 à 17:50, Jonas Hahnfeld a écrit : > > Am Dienstag, den 23.06.2020, 15:54 +0200 schrieb Valentin Villenave: > > > - 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). Yes, see: https://lists.gnu.org/archive/html/lilypond-devel/2020-05/msg00323.html Actually, it might be a good idea to deal with these issues before running the script, so all (initial) milestones can be assigned automatically. Ok for everyone? Jonas signature.asc Description: This is a digitally signed message part
scoped labels (was: Re: [RFC] Use GitLab Milestones)
Am Dienstag, den 23.06.2020, 13:04 -0400 schrieb Dan Eble: > On Jun 23, 2020, at 04:40, Jonas Hahnfeld wrote: > > Pretty much that: You can only have one label from the same scope, and > > assigning a second automatically removes the old (cf. Patch::*). I > > actually agree that multiple Type's might be useful. If others are in > > favor as well, we can just rename the labels. > > My default position is to avoid restrictions when there isn't a good reason > for them. There are some types in the current set that I can't imagine using > together – for example (Enhancement|Maintainability) with > (Crash|Defect|Regression) – but unless that endangers the efficiency of > someone's workflow, I don't think we should spend time compartmentalizing > them. > > Patch::* obviously need to remain scoped because they name states in a state > machine. I think there's agreement that: * Type::* should be made plain labels. * Patch::* must stay scoped. I can do the renaming of Type::* if nobody objects. What about: * Needs::* (currently design, evidence, policy); and * Status::* ? We can of course leave them as-is (for now), but I thought I'd just bring this up. Jonas signature.asc Description: This is a digitally signed message part
Re: [RFC] Use GitLab Milestones
Am Mittwoch, den 24.06.2020, 12:41 +0200 schrieb 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. I think it should mean that because the operation is destructive. The logic of the scripts might be relatively sound, but you never know what will be the corner cases before you notice them. > > > - 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=closed_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=%E2%9C%93=closed_title=None[label_name][]=Status%3A%3AInvalid[label_name][]=Type%3A%3AInvalid As you can see already from the first page, there are many issues without information when the problem was fixed. I don't want to go through all of them in order to make the procedure work. > > 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. I was referring to "The new way of saying Status::Fixed is to close the issue". > 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. Seems simple enough to do, there are only 2 issues with Type::Invalid. Jonas > Best, > Jean signature.asc Description: This is a digitally signed message part
Re: [RFC] Use GitLab Milestones
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=closed_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=%E2%9C%93=closed_title=None[label_name][]=Status%3A%3AInvalid[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
Re: [RFC] Use GitLab Milestones
James writes: > On 23/06/2020 20:47, Jonas Hahnfeld wrote: >> Never understood the difference between Started and Accepted either. Presumably "New" and "Accepted". "Started" means that somebody is working on it, to avoid duplication of effort. > > While we have definitions in the CG as Carl pointed out the context of > this was, if I remember correctly, to a make sure developers could see > clearly if a tracker issue entered had been at least checked by > someone who knew LP against the issue and that the issue itself that > it was 'valid' than perhaps a duplicate of something else, or was > fixed in a later (unstable) versions, or that the issue 'needed > evidence' or 'examples of real-world scores' before they were > considered worth working on. > > It's the equivalent of 'Verified' but for newly entered issues. > > A LP developer who created an issue with a patch/fix would simply jump > to 'started'. > > This was something else that a 'non-developer' could contribute to the > LP project so developers could get on with fixing issues. > > Regards > > James > > > > > -- David Kastrup
Re: [RFC] Use GitLab Milestones
On 23/06/2020 20:47, Jonas Hahnfeld wrote: Never understood the difference between Started and Accepted either. While we have definitions in the CG as Carl pointed out the context of this was, if I remember correctly, to a make sure developers could see clearly if a tracker issue entered had been at least checked by someone who knew LP against the issue and that the issue itself that it was 'valid' than perhaps a duplicate of something else, or was fixed in a later (unstable) versions, or that the issue 'needed evidence' or 'examples of real-world scores' before they were considered worth working on. It's the equivalent of 'Verified' but for newly entered issues. A LP developer who created an issue with a patch/fix would simply jump to 'started'. This was something else that a 'non-developer' could contribute to the LP project so developers could get on with fixing issues. Regards James
Re: [RFC] Use GitLab Milestones
Am Dienstag, den 23.06.2020, 23:40 +0200 schrieb Valentin Villenave: > On 6/23/20, Jonas Hahnfeld wrote: > > I knew that description and, honestly, that would be a show stopper for > > me reporting any issue to a project in 2020. > > Why? Because mailing lists are a thing of the past in your view? :-) IMO reporting bugs via a mailing list is a thing of the past. Mailing list are great for communication inside an established team (and to be honest: I prefer the threading mode of my mail clients over any forum / Discord / ...). > Sending an e-mail to an open mailing list is much more universal and > accessible than requiring a GitLab subscription (which mandates to go > through at least one if not several Google ReCaptchas, is blocking > some public proxies and Tor nodes, etc.). I didn't say we should stop accepting bug reports via the mailing list, but part of the story for using gitlab.com has been that others already have an account. > It’s simple enough: we don’t forbid anyone from opening issues > directly on the tracker, We did this on SourceForge, we only gained more openness by migrating to GitLab. > but we do discourage it because most of the > time it turns to be either not a bug (LilyPond is a complex program > with its fair share of unexpected or inconsistent behaviors) or an > already known bug (and with 6000 tracker pages of which more than 1000 > are still open, finding duplicates is actually pretty difficult for a > newcomer). > > Besides, going through the bug list allows users to interact with > knowledgeable people who (unlike on -user) are used to turning a large > example into a minimal one, to translating layman terms into LilyPond > jargon that the devs are more likely to be familiar with, etc. Look > for example at this recent issue opened directly on the tracker, and > compare the original report (which I had to re-label and edit because > of a Markdown syntax error) with the comment I left: > https://gitlab.com/lilypond/lilypond/-/issues/6004 It's exactly this explanation that would turn me away from submitting bugs: The general claim that a user can't write decent bug reports. IMHO this completely misses the fact that there are clever people out there who are perfectly able to write detailed bug reports that are useful even if not using LilyPond terms. Jonas > On the Google tracker (IIRC), any new issue was automatically given > the label Status::New. That doesn’t seem to be the case here, so there > *could* be an argument that “unlabelled” should be the new > “Status::New”. I don’t like it that much (ideally, “Status” should > behave like “Patch” and follow a predictable sequence of states, from > “New” to “Verified”) but if that’s technically more convenient, why > not. > > Cheers, > -- V. signature.asc Description: This is a digitally signed message part
Re: [RFC] Use GitLab Milestones
On 6/23/20, Jonas Hahnfeld wrote: > I knew that description and, honestly, that would be a show stopper for > me reporting any issue to a project in 2020. Why? Because mailing lists are a thing of the past in your view? :-) Sending an e-mail to an open mailing list is much more universal and accessible than requiring a GitLab subscription (which mandates to go through at least one if not several Google ReCaptchas, is blocking some public proxies and Tor nodes, etc.). It’s simple enough: we don’t forbid anyone from opening issues directly on the tracker, but we do discourage it because most of the time it turns to be either not a bug (LilyPond is a complex program with its fair share of unexpected or inconsistent behaviors) or an already known bug (and with 6000 tracker pages of which more than 1000 are still open, finding duplicates is actually pretty difficult for a newcomer). Besides, going through the bug list allows users to interact with knowledgeable people who (unlike on -user) are used to turning a large example into a minimal one, to translating layman terms into LilyPond jargon that the devs are more likely to be familiar with, etc. Look for example at this recent issue opened directly on the tracker, and compare the original report (which I had to re-label and edit because of a Markdown syntax error) with the comment I left: https://gitlab.com/lilypond/lilypond/-/issues/6004 On the Google tracker (IIRC), any new issue was automatically given the label Status::New. That doesn’t seem to be the case here, so there *could* be an argument that “unlabelled” should be the new “Status::New”. I don’t like it that much (ideally, “Status” should behave like “Patch” and follow a predictable sequence of states, from “New” to “Verified”) but if that’s technically more convenient, why not. Cheers, -- V.
Re: [RFC] Use GitLab Milestones
On Tue, Jun 23, 2020 at 2:25 PM Jonas Hahnfeld wrote: > > Am Dienstag, den 23.06.2020, 14:11 -0600 schrieb Carl Sorensen: > > Accepted: the Bug Squad added it, or reviewed the item. > > Started: a contributor is working on a fix. Owner should change to be > > this contributor. > > > > Closed issues: > > > > Invalid: issue should not have been added in the current state. > > Duplicate: issue already exists in the tracker. > > Fixed: a contributor claims to have fixed the bug. The Bug Squad > > should check the fix with the next official binary release (not by > > compiling the source from git). Owner should be set to that > > contributor. > > Verified: Bug Squad has confirmed that the issue is closed. This means > > that nobody should ever need look at the report again – if there is > > any information in the issue that should be kept, open a new issue for > > that info. > > Which one of those would apply to an issue like > https://gitlab.com/lilypond/lilypond/-/issues/6000 ? > My guess is that it should be Accepted. It's a real issue, not an imaginary one. I believe that the proper fix for this issue is to make our configuration check for fontforge see whether python scripting is enabled, and if not, to generate a message informing the user of that fact. I don't think it's fixed, because it's easy to set up a system with FontForge not having python scripting enabled. But that's just my opinion. Thanks, Carl
Re: [RFC] Use GitLab Milestones
Am Dienstag, den 23.06.2020, 14:11 -0600 schrieb Carl Sorensen: > On Tue, Jun 23, 2020 at 2:04 PM Jonas Hahnfeld wrote: > > Am Dienstag, den 23.06.2020, 20:54 +0200 schrieb Jean Abou Samra: > > > Hi, > > > > > 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 > > > > From the Contributors' Guide: > > Open issues: > > New: the item was added by a non-member, despite numerous warnings not > to do this. Should be reviewed by a member of the Bug Squad. I knew that description and, honestly, that would be a show stopper for me reporting any issue to a project in 2020. > Accepted: the Bug Squad added it, or reviewed the item. > Started: a contributor is working on a fix. Owner should change to be > this contributor. > > Closed issues: > > Invalid: issue should not have been added in the current state. > Duplicate: issue already exists in the tracker. > Fixed: a contributor claims to have fixed the bug. The Bug Squad > should check the fix with the next official binary release (not by > compiling the source from git). Owner should be set to that > contributor. > Verified: Bug Squad has confirmed that the issue is closed. This means > that nobody should ever need look at the report again – if there is > any information in the issue that should be kept, open a new issue for > that info. Which one of those would apply to an issue like https://gitlab.com/lilypond/lilypond/-/issues/6000 ? Jonas > > HTH, > > Carl > signature.asc Description: This is a digitally signed message part
Re: [RFC] Use GitLab Milestones
On Tue, Jun 23, 2020 at 2:04 PM Jonas Hahnfeld wrote: > > Am Dienstag, den 23.06.2020, 20:54 +0200 schrieb Jean Abou Samra: > > Hi, > > 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 > >From the Contributors' Guide: Open issues: New: the item was added by a non-member, despite numerous warnings not to do this. Should be reviewed by a member of the Bug Squad. Accepted: the Bug Squad added it, or reviewed the item. Started: a contributor is working on a fix. Owner should change to be this contributor. Closed issues: Invalid: issue should not have been added in the current state. Duplicate: issue already exists in the tracker. Fixed: a contributor claims to have fixed the bug. The Bug Squad should check the fix with the next official binary release (not by compiling the source from git). Owner should be set to that contributor. Verified: Bug Squad has confirmed that the issue is closed. This means that nobody should ever need look at the report again – if there is any information in the issue that should be kept, open a new issue for that info. HTH, Carl
Re: [RFC] Use GitLab Milestones
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 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=closed_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
Re: [RFC] Use GitLab Milestones
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 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 http://lilypond.org/doc/v2.19/Documentation/contributor/bug-squad-checklists , 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 https://gitlab.com/lilypond/lilypond/-/issues?scope=all=closed_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. 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.
Re: [RFC] Use GitLab Milestones
On Jun 23, 2020, at 04:40, Jonas Hahnfeld wrote: >> > Pretty much that: You can only have one label from the same scope, and > assigning a second automatically removes the old (cf. Patch::*). I > actually agree that multiple Type's might be useful. If others are in > favor as well, we can just rename the labels. My default position is to avoid restrictions when there isn't a good reason for them. There are some types in the current set that I can't imagine using together – for example (Enhancement|Maintainability) with (Crash|Defect|Regression) – but unless that endangers the efficiency of someone's workflow, I don't think we should spend time compartmentalizing them. Patch::* obviously need to remain scoped because they name states in a state machine. — Dan
Re: [RFC] Use GitLab Milestones
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. > > 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? > - 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). > > > we should disable notifications of the lilypond project for that time frame. > > OK. To be clear: I'll do this from the project side (there's a global "Disable email notifications" for the project), no need to make any change for your personal notification settings. Jonas > > Cheers, > -- V. > signature.asc Description: This is a digitally signed message part
Re: [RFC] Use GitLab Milestones
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. Sounds good. I only have a few questions: - How do you plan to indicate backports? (Granted, this is a very limited subset.) - 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? > we should disable notifications of the lilypond project for that time frame. OK. Cheers, -- V.
Re: [RFC] Use GitLab Milestones
Hi James, Am Dienstag, den 23.06.2020, 08:00 +0100 schrieb James: > Hello > > On 22/06/2020 18:33, 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. > > Just so you know I have just gone through all the 'Fixed_' labels this > morning and they are all consistent now. > > The form is > > Fixed_X_XX_XX > > e.g Fixed _2_04_01 or Fixed_2_19_01 > > There was no consistency for single digit or version 'zero' builds so I > made sure they always had 2 numerals even they were '00' just in case > this helps with find/replace. Okay, didn't notice that one. Do we want to retain this? Right now, I'm parsing integer numbers, so the milestones would be "2.4.1" and "2.19.1" for the two examples above. I think this matches what the releases advertise themselves, but not sure. > > [...] > > > > The bad news is that both creating and assigning a milestone induce > > notifications. We likely don't want to receive 4000 emails when running > > the scripts, so we should disable notifications of the lilypond project > > for that time frame. This means contributions during that period (~30 > > minutes?) might stay under the radar at first, but that's probably > > acceptable. > That's a good idea. Perhaps block all access for that period (can you do > that easily and informatively?). I fear I can't for external contributors, at least not without possibly breaking a bunch of stuff: * Making the whole repo private might disassociate forks. * Not sure what happens to existing MRs if I disable them for the repo. Plus issues have to stay active, that's the point of running the scripts. However, I think disabling notifications leaves the activity stream working (see https://gitlab.com/lilypond/lilypond/activity) and this will only show entries when creating the milestones, ie not when assigning issues. Skipping ~330 entries sounds feasible for checking that nothing was lost, plus you can filter for "Issue events" (new issues) and "Comments". So the whole topic is less bad than I initially thought. > > Let me know what you think! > > There is one thing that I find with the labels (and I don't care either > way) its those of the form > > Type::XXX vs just a normal string > > e.g. Type::Maintainabilty vs just Maintainability. > > You cannot have two labels of Type::XXX on the same issue. So an issue > that was labelled 'Font' AND 'Scripts' in the past, for instance, could > not be both Type::Font AND Type::Scripts. One replaces the other (at > least when I tested it manually). Not exactly related to this one, but I think there was at most one 'Type' on SourceForge as well, so scoped labels looked like the corresponding thing on GitLab. > Is this XXX:: what they call 'scoping'? Anyway, we're a few 'non-scoped' > labels out there and I wonder (apart from the 'Patch::' labels) what the > pros and cons of having a XXX:: label vs just a string. Pretty much that: You can only have one label from the same scope, and assigning a second automatically removes the old (cf. Patch::*). I actually agree that multiple Type's might be useful. If others are in favor as well, we can just rename the labels. Jonas > > James signature.asc Description: This is a digitally signed message part
Re: [RFC] Use GitLab Milestones
Hello On 22/06/2020 18:33, 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. Just so you know I have just gone through all the 'Fixed_' labels this morning and they are all consistent now. The form is Fixed_X_XX_XX e.g Fixed _2_04_01 or Fixed_2_19_01 There was no consistency for single digit or version 'zero' builds so I made sure they always had 2 numerals even they were '00' just in case this helps with find/replace. 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. This topic already surfaced right after the migration to GitLab, but now I finally had the chance to look into this with more detail. In particular we now seem to have a common naming for the labels in question (great work by James!) which makes scripting much more feasible. I've already started to write scripts to create the 328 milestones (that's what they tell me) and automatically assign 3662 issues which have exactly one label of the form mentioned above. Additionally, my scripts think that there are 277 issues with two or more labels (attached to this message). Most are instances of "fix was backported to a stable version", but I'd like to check them manually. 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 The bad news is that both creating and assigning a milestone induce notifications. We likely don't want to receive 4000 emails when running the scripts, so we should disable notifications of the lilypond project for that time frame. This means contributions during that period (~30 minutes?) might stay under the radar at first, but that's probably acceptable. That's a good idea. Perhaps block all access for that period (can you do that easily and informatively?). Let me know what you think! There is one thing that I find with the labels (and I don't care either way) its those of the form Type::XXX vs just a normal string e.g. Type::Maintainabilty vs just Maintainability. You cannot have two labels of Type::XXX on the same issue. So an issue that was labelled 'Font' AND 'Scripts' in the past, for instance, could not be both Type::Font AND Type::Scripts. One replaces the other (at least when I tested it manually). Is this XXX:: what they call 'scoping'? Anyway, we're a few 'non-scoped' labels out there and I wonder (apart from the 'Patch::' labels) what the pros and cons of having a XXX:: label vs just a string. James
