All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.