From: Sam James <sam@gentoo.org>
To: Alejandro Colomar <alx@kernel.org>
Cc: Sam James <sam@gentoo.org>,
"G. Branden Robinson" <g.branden.robinson@gmail.com>,
linux-man@vger.kernel.org
Subject: Re: groff 1.23.0 stability (was: using the TQ macro)
Date: Mon, 13 Nov 2023 23:48:29 +0000 [thread overview]
Message-ID: <87wmulnri2.fsf@gentoo.org> (raw)
In-Reply-To: <ZUDvXuA3MVZVSOF7@debian>
Alejandro Colomar <alx@kernel.org> writes:
> [[PGP Signed Part:Undecided]]
> Hi Sam!
>
> On Tue, Oct 31, 2023 at 04:38:13AM +0000, Sam James wrote:
>> "G. Branden Robinson" <g.branden.robinson@gmail.com> writes:
>> > At 2023-10-25T17:08:19+0200, Alejandro Colomar wrote:
>> >> BTW, I just checked and Gentoo still doesn't consider 1.23.0 stable
>> >> enough <https://packages.gentoo.org/packages/sys-apps/groff>. :|
>> >
>>
>> Alex, this is based on a misunderstanding of how our process works -- please
>> CC me if you have questions or if something looks off in future, so I
>> can explain/help if required.
>>
>> > I don't understand that claim. 1.23.x is as stable as it can be; there
>> > have been no point releases. Its behavior is not changing based on the
>> > calendar.
>>
>> The standard rule in Gentoo is 30 days after something has been released
>> before it's considered for "stabilisation". We wait longer for critical
>> packages like groff to give more time for any reported bugs in "~arch"
>> (our testing area, which a lot of users participate in). It is generally
>> not a comment on upstream stability at all.
>
> Yep, I understand it's just about your use in combination with other
> packages in your distribution. What I'm not sure is if by default
> Gentoo installs the stable packages or the testing ones. If you install
> by default the stable one, I wouldn't want to force a dependency on a
> package that you don't yet install by default.
That's no problem - we regularly have things which require a new
dependency to become stable and it's a nudge if it hasn't happened anyway.
(See below).
>
>>
>> > I have to assume that there are either changes since 1.22.4
>> > documented in NEWS (and if not, that's probably a bug) that they're
>> > concerned about, or they're worried the broader community hasn't gotten
>> > enough exposure to it yet. repology.org has been sitting at 64
>> > instances of groff 1.23.0 for weeks now; I think pretty much everyone
>> > who's going to adopt it has done so by now.
>> >
>>
>> ... in this case, the only blockers were really:
>> * me having https://github.com/Perl/perl5/issues/21239
>> in the back of my head (wasn't paying full attention, just knew I had
>> to go back and read any developments/further comments)
>>
>> * needing to look into a reported failure
>> (https://bugs.gentoo.org/910226) - which looks like it should be fixed
>> when we update our version of openvswitch (or we backport the patch,
>> or both)
>
> So, if the Linux man-pages forces a dependency of groff-1.23.0, would it
> be problematic for Gentoo before you declare it stable, or would it be
> fine?
Yeah, this is fine - go ahead. The only issue would really be if
groff-1.23.0 was causing many issues which would prevent us from
unleashing newer man-pages any time soon, but that is not the case.
>
>>
>> > CCing Sam James (the only Gentoo developer I know by name, because he's
>> > been active some of the same places I have been) in case he can throw
>> > some light on this.
>>
>> Happily! Please feel free to loop me in if you reckon I can give input
>> on things.
>>
>> So, all in all, none of this is a reflection on upstream, just a mix
>> of: how we do things normally (waiting a bit post-release unless there's
>> some serious regression in our stable version), waiting a bit longer
>> because it's a critical package (sometimes 60 days, sometimes a bit
>> longer), and not getting around to looking at that openvswitch bug yet.
>
> Yeah, the quality of groff-1.23.0 is way better than 1.22.4. I'm just
> worried that forcing distros to use it too early might be detrimental.
>
> Cheers,
> Alex
>
>>
>> I promise I would report any problems if I determined they were in any
>> way an upstream issue :)
>>
>> Thanks for reaching out.
>>
>> >
>> > Regards,
>> > Branden
>> >
>>
>> best,
>> sam
>>
thanks,
sam
next prev parent reply other threads:[~2023-11-13 23:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-25 14:11 using the TQ macro G. Branden Robinson
2023-10-25 15:08 ` Alejandro Colomar
2023-10-28 13:13 ` groff 1.23.0 stability (was: using the TQ macro) G. Branden Robinson
2023-10-31 4:38 ` Sam James
2023-10-31 12:13 ` Alejandro Colomar
2023-11-13 23:48 ` Sam James [this message]
2023-11-14 0:25 ` Alejandro Colomar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wmulnri2.fsf@gentoo.org \
--to=sam@gentoo.org \
--cc=alx@kernel.org \
--cc=g.branden.robinson@gmail.com \
--cc=linux-man@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox