Re: [groff] Savannah bug field usage protocol

[Ingo Schwarze]

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] :)