Re: groff 1.23.0.rc2 readiness

[Ingo Schwarze]

Hi Branden,

G. Branden Robinson wrote on Wed, Aug 24, 2022 at 07:11:10AM -0500:
> At 2022-08-24T21:18:02+1000, John Gardner wrote:
>> Bertrand wrote:

>>> As you are the most active developer, would you consider taking over
>>> the maintainership of groff?

>> Please, please, *please* let that be a "yes"…

> Bertrand and I are in private correspondence about this.
> One or both of us will follow up to the list as things progress.

Very good news, this is nice.
Also, my best wishes for Bertrands further and speedy recovery!

> There's a lot of FSF procedure to deal with.

Wouldn't it be better to simply abandon the the GNU roff project
(i.e. leaving the FSF with no developer whatsoever), fork groff under
a new name (say, "GPL roff"), and continue that new project outside
the FSF?  This is not the first time FSF red tape has proven onerous
to the point of creating major distractions from and significant
obstacles to real development work.

Of course, the FSF would retain copyright of the existing GPLv3+ code.
But that's not a problem because a free software license, once granted,
cannot be retracted.  Future contributors could simply contribute in
their own name, without transfering Copyright, under GPLv3+.

Of course, if most developers love the FSF, i'm not pressing for that
change as i'm only mildly affected by the red tape.  I believe
some others suffer more from it than i do (even though it did
cause me some waste of time on a few occasions).

> But for the sake of transparency, in the meantime, he asked if the
> current HEAD was good enough to tag as "rc2" and I said "yes".

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".  The purpose of an RC is to have
it tested on as many platforms and for as many different purposes as
possible, to confirm that indeed no undiscovered regressions exist
and that in particular the last few commits made before the RC did not
cause regressions.  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.

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.
After the RC, it is the critical to not commit anything except fixes
for critical regressions that people reported from RC testing.
In particular, after an RC, no bugs must be fixed that were already
known before the RC was sent out.

Not only do we have a significant numbers of open blockers, but i
also reported that the mandoc test suite found thirty-seven changes
of behaviour between the last groff release and groff-current that
i did not find the time to analyze just jet (in addition to changes
that i already investigated and that turned out to be in part groff
regressions, in part mandoc bugs, and in part intentional and useful
changes in groff behaviour).

So it is totally obvious to me that the code base is *not* in a good
shape and quite far from being ready for an RC.

Of course we shouldn't defer the relase until after Judgement Day,
and it does help to have a rough idea about when we wish to get ready
for an RC.  I think if we decide now "no more commits except those
considered release-critical" then we will need at least two or three
weeks to get to a state that might support an RC, with some luck.
If things go not so well, we might need the month of October for
sorting out the remaining issues, too, but aiming for an RC between
late September and late October would seem reasonable to me.  In that
case, even if the RC reveals a so far undiscovered, major regression
(or a small number of such), time should be sufficient to fix those
and release before the beginning of December.  This is not intended
as a rigid plan, but as a rough idea what we are aiming for.

> I'd like to encourage people with an interest in groff to step up and
> become contributors if they can.  I think having the "lead developer"
> (or "most active" one, at any rate) and "release manager" be separate
> people can be a good separation of concerns.
> 
> In a peer relationship where there's mutual respect and comity, having
> one person focussed on "this is good, let's make this a release,
> announce the good work that's been done, and get it in people's hands"
> and other on "we can make it even better: let's fix this bug and improve
> that feature" can be a healthy dynamic for development.

Agreed.  In a small project, this separation of concerns is not
strictly required but still healthy and useful if possible.
It requires finding yet another person able and willing to deal
with FSF overhead in addition to development work, though.

Yours,
  Ingo