Re: groff maintainership, release, and blockers (was: groff 1.23.0.rc2 readiness)

[Ralph Corderoy]

Hi Branden,

> > Wouldn't it be better to simply abandon the the GNU roff project
...
> The FSF provides useful infrastructure.  Consider the risks of
> relocating to a site like GitHub

(Just a reminder that the FSF also provide https://savannah.nongnu.org
which is presumably the same underlying system.)

> > Sorry, i fail to understand that.  The acronym "RC" stands for
> > "release candidate".  I would define a "release candidate" as "a
> > version that is believed to be ready for release".
>
> Apparently we have a terminological and/or philosophical disagreement.

I urge resolving this disagreement by moving towards the standard
definitions which Ingo, other packagers, and the RotW use.

> Therefore, by that standard, any commit not marked "Test fails at this
> commit."..._is a release candidate_.

No, an RC is, all things going well, what should be the next release:
a culmination of effort into a neat boundary of features, code, tests,
and documentation.

Announcing an RC causes work for others and to lessen that, the changes
between RCs should be just what's needed to polish the RC to make it
nearer to being the release.  Ongoing development not intended for this
release should occur elsewhere.

> > These tests cause non-trivial work for significant numbers of
> > people, most of whom are *not* groff developers, so an RC should
> > only be made when the software is really believed to be ready - both
> > out of respect for testers' time and because releasing multiple RCs
> > will weary out testers and increase the likelihood of serious bugs
> > slipping into the release: some testers will not have the time to
> > test over and over again, so the more RCs you ship, the less test
> > coverage you get.
>
> I agree with this, but I reiterate that, in a sense, we've had
> literally thousands of RCs since groff 1.22.4.

No, commits are not RCs because an RC is announced as such.

> > In particular, i'm firmly convinced that issuing an RC while even
> > one single blocker issue is unresolved is a blatant contradiction.
> > Before an RC, all blockers must either be resolved or explicitly
> > re-classified as "not release critical" and re-scheduled for the
> > subsequent release.
>
> Well, then, in a sense we don't have _any_ blockers, because "the tree
> isn't red".

Right, blocker is being misused for what's an aspiration to see an issue
fixed in a release.  Again, this confuses by misusing a well-understood
term.

> On the other hand, applying your definition strictly, we'd almost
> never have any blocker bugs at all.

If a document unintentionally renders differently then the release
shouldn't occur.  An expanding corpus of real-life documents can be
turned to pixels for comparing with the golden version.  Then things
like https://savannah.gnu.org/bugs/index.php?24047 wouldn't slip
through.  Writing individual tests for features isn't a substitute; both
are needed.

> So, we could indeed stop using the Savannah Blocker severity for the
> purpose I'm employing it.

Should rather than could.

> But I ask you: what _good_ would that do, apart from satisfying your
> personal esthetic of release management?

It would avoid confusion by deviating from standard definitions which in
turn might put off contributors because of the impression it gives.

-- 
Cheers, Ralph.