Re: [groff] Savannah bug field usage protocol
At 2018-04-22T11:29:39+0100, Colin Watson wrote: > On Sat, Apr 21, 2018 at 05:43:12PM -0400, G. Branden Robinson wrote: > > Our commit discipline is already supposed to include updating the > > ChangeLog, and, where appropriate, NEWS files as part of the commit > > where the underlying change is made. Do you think that should suffice > > for aiding the preparation of Release Notes? > > I agree with the sentiment, but do the ~40 lines of NEWS entries since > 1.22.3 really reflect the ~1900 lines of ChangeLog for the same period? > I'm not really qualified to prepare updates there, but the ratio seems > unusually low to me. I'm sure those 40 lines don't cover all the work. We have a release manager now; I'd say it's up to Bertrand to delegate that task to some unfortunate victim, er, volunteer. ;-) -- Regards, Branden signature.asc Description: PGP signature
Re: [groff] Savannah bug field usage protocol
On Sat, Apr 21, 2018 at 05:43:12PM -0400, G. Branden Robinson wrote: > At 2018-04-21T14:21:03+0100, Ralph Corderoy wrote: > > Some projects maintain a `pending' release notes so that significant > > fixes and changes get added to as they're implemented. This might avoid > > the need to keep some bugs non-closed until the release. Come release, > > the file's reviewed, some minor things with highsight ditched, and the > > commit log scanned for anything missing. > > Our commit discipline is already supposed to include updating the > ChangeLog, and, where appropriate, NEWS files as part of the commit > where the underlying change is made. Do you think that should suffice > for aiding the preparation of Release Notes? I agree with the sentiment, but do the ~40 lines of NEWS entries since 1.22.3 really reflect the ~1900 lines of ChangeLog for the same period? I'm not really qualified to prepare updates there, but the ratio seems unusually low to me. -- Colin Watson [cjwat...@debian.org]
Re: [groff] Savannah bug field usage protocol
At 2018-04-21T14:21:03+0100, Ralph Corderoy wrote: > Hi, > > Ingo wrote: > > All of this can and should be disregarded for changes that are so > > minor that they will definitely never be mentioned in release notes or > > similar. > > Some projects maintain a `pending' release notes so that significant > fixes and changes get added to as they're implemented. This might avoid > the need to keep some bugs non-closed until the release. Come release, > the file's reviewed, some minor things with highsight ditched, and the > commit log scanned for anything missing. Our commit discipline is already supposed to include updating the ChangeLog, and, where appropriate, NEWS files as part of the commit where the underlying change is made. Do you think that should suffice for aiding the preparation of Release Notes? -- Regards, Branden signature.asc Description: PGP signature
Re: [groff] Savannah bug field usage protocol
Hi, Ingo wrote: > All of this can and should be disregarded for changes that are so > minor that they will definitely never be mentioned in release notes or > similar. Some projects maintain a `pending' release notes so that significant fixes and changes get added to as they're implemented. This might avoid the need to keep some bugs non-closed until the release. Come release, the file's reviewed, some minor things with highsight ditched, and the commit log scanned for anything missing. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy
Re: [groff] Savannah bug field usage protocol
Hi Branden, that all sounds very reasonable to me, for actual bugs. I'd only suggest one additional simplification: All of this can and should be disregarded for changes that are so minor that they will definitely never be mentioned in release notes or similar. That is certainly the case for anything so minor that it doesn't warrant a ChangeLog entry, but i think it also applies to trivial changes that, for whatever reason, do have a ChangeLog entry. For such trivial tickets, figuring out whether the typo (or whatever it is) was present in a release, setting the "Planned Release" field, keeping them open, and revisiting them later looks like a waste of time and effort to me and besides clutters the bug list. For example, i think that the following trivial tickets ought to be closed right away: 27422 50990 51071 51076 51078 51417 51426 51482 51483 51502 51513 51540 51541 51888 51598 51609 51610 51611 51695 52333 52335 52374 52442 52444 52458 52462 That is all stuff you definitely *never* want to look at again, under no circumstances, and it makes it hard to see actual bugs that have been fixed. Of course, it is a matter of taste where exactly to draw the line between "trivial, get this out of my sight" and "bug fixed, may be relevant for release notes", and absolute consistency is neither possible nor required, but the groff bugtracker is so noisy that i think getting rid of the worst trivialities would be beneficial. Yours, Ingo G. Branden Robinson wrote on Sat, Apr 21, 2018 at 06:58:51AM -0400: > As far as I know, there is no documentation about how we're supposed to > be using the Open/Closed and Planned Release fields in Savannah. > > Ingo closes bugs whose status he sets to Invalid, but that's not the > case I'm interested in. > > I'd like to propose that: > > 1. A Fixed bug be Closed immediately[1] if it was only ever extant in > git, and not in an actual release (not counting release candidates). > > 2. The Planned Release field be used and set to the forthcoming release > for Fixed bugs that were extant in the most recent actual release. > > 3. That the Owner of a Fixed bug in a Planned Release Close the bug when > that Planned Release is actually released. > > My rationales are: > > A. I am owner of a bunch of fixed groff bugs in Savannah and I'd like to > tidy them up in some respect. > > B. From repeated personal negative experiences, I have come to hate it > when a project slams a bug closed as soon as a commit fixing it is made, > no matter how many months or years may pass before a release is made. > If the bug exists in the latest release version of a software project, > that bug should be easy to find. This also helps prevent the filing of > duplicate reports. > > C. This keeps the cost of experimentation low on git HEAD. There's no > reason to wear our (my[2]) shame on the bug tracker for screwups that > never made it into an actual release. Getting yelled at on the mailing > list is a good enough deterrent. > > Thoughts? > > [1] Meaning: as soon as the commit is pushed, or reasonably soon > thereafter, or as soon as someone notices this is the case. > > [2] :)
[groff] Savannah bug field usage protocol
As far as I know, there is no documentation about how we're supposed to be using the Open/Closed and Planned Release fields in Savannah. Ingo closes bugs whose status he sets to Invalid, but that's not the case I'm interested in. I'd like to propose that: 1. A Fixed bug be Closed immediately[1] if it was only ever extant in git, and not in an actual release (not counting release candidates). 2. The Planned Release field be used and set to the forthcoming release for Fixed bugs that were extant in the most recent actual release. 3. That the Owner of a Fixed bug in a Planned Release Close the bug when that Planned Release is actually released. My rationales are: A. I am owner of a bunch of fixed groff bugs in Savannah and I'd like to tidy them up in some respect. B. From repeated personal negative experiences, I have come to hate it when a project slams a bug closed as soon as a commit fixing it is made, no matter how many months or years may pass before a release is made. If the bug exists in the latest release version of a software project, that bug should be easy to find. This also helps prevent the filing of duplicate reports. C. This keeps the cost of experimentation low on git HEAD. There's no reason to wear our (my[2]) shame on the bug tracker for screwups that never made it into an actual release. Getting yelled at on the mailing list is a good enough deterrent. Thoughts? [1] Meaning: as soon as the commit is pushed, or reasonably soon thereafter, or as soon as someone notices this is the case. [2] :) -- Regards, Branden signature.asc Description: PGP signature