Hi Bertrand, Bertrand Garrigues via wrote on Fri, Aug 26, 2022 at 11:53:07PM +0200: > On Fri, Aug 26 2022 at 02:04:57 PM, G. Branden Robinson wrote: >> At 2022-08-26T13:51:25+0200, Ingo Schwarze wrote:
>>> 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. > I understand your point Ingo, however the rc1 tag is almost 2 years old, Yes, no argument about the RC1 tag going wrong and being useless now. > so I feel we need to make a new tag now, and from this tag decide > which bugs must absolutely be fixed. I'm not convinced deciding which issues shall be fixed and which postponed needs a tag, nor that calling such a tag an "RC" is easy to understand, but i think Branden is right that's only a terminolgical argument after all. > I won't release any official 1.23.0 if you consider there is a blocker > or that the mandoc is not in a good shape. Actually, i deem the state of mandoc irrelevant in this context. It is perfectly fine to release groff while mandoc is in an unstable state. (As a matter of fact, mandoc is not close to release-ready right now: it has various open bugs and some unfinished work, but that is off-topic here.) > For sure there will be some bug fixes after rc2 and we'll have an rc3, > so it's perhaps not exactly a "Release Candidate", it's a kind of > "intermediate tag" or an "alpha release", but I'll still name it rc2, > for the sake of simplicity. Fair enough, file name consistency is a plus. It is desirable for the announcement be clear about the intended purpose of RC2, though. > Could you please detail here what is your list of blockers that you > think must be absolutely fixed before the official 1.23.0 release? I cannot give a final list off the top of my head because i am aware of several candiadates of regressions that require analysis. Are you planning to move towards an RC during the next two to three weeks? In that case, i should probably priotize triage over fixing which i usually avoid (if possible) because it increases the total working time consumed. But it would speed up drafting a list of potential issues that might be worth fixing before release. I recommend investigating this one before RC2, if feasible: #62918 Wrong GhostScript version reported during build There remains a regression in man(7) .EX/.EE which i will report ASAP. Even though this is documentation only, i recommend resolving it before RC3 because switching back and forth in terminology in three consecutive releases could be regarded as awkward: #62816 rename the \& escape...again I recommend postponing these until after release: #62774 [mdoc] warn if any of `Dd`, `Dt`, `Os` not called #62926 [mdoc] align styling of titles and man page cross references with man(7) #62933 [man] produce hyperlinks in PDF output Yours, Ingo
