Re: "up to date at all costs" is a failed approach

[Jonathan Perkin <jperkin%mnx.io@localhost>]

* On 2024-07-15 at 19:52 BST, Rob Whitlock wrote:

> How would this be different from the quarterly stable branches?
I currently actively sit in two different open source worlds, where the 
development approaches could not be more different.
In the NetBSD/pkgsrc world, changes are made ad-hoc to a development 
branch that may or may not be complete or fully tested.  Then, after a 
certain period of time, the tree is frozen and subsequently branched as 
a new release once any known issues are ironed out.
In the illumos world, there is the principle of First Customer Ship 
(FCS) quality all the time, inherited from Sun.  It basically means you 
should be able to cut the tree at any point in time and ship it directly 
to customers with full confidence that it has no outstanding bugs.  
Changes are never made to the tree until they have been fully reviewed 
and considered complete.
  https://www.illumos.org/docs/contributing/quality/

Basically I want a tree that is closer to the Sun/illumos model, but 
using automated builds for the majority of the review process.  It would 
essentially be a rolling stable release, where you can be confident that 
every package will build correctly everywhere, at the cost of not always 
having bleeding edge versions available.
Personally I wouldn't use the "stable" nomenclature for the pkgsrc 
branches.  "Snapshot" is probably a more accurate term.  There's no 
guarantee, certainly on platforms other than NetBSD, that a pkgsrc 
branch will contain more working packages and fewer bugs than any 
other arbitrary point-in-time of the tree.
> What would the consequences of it being "considered fatal" be? Does 
> that mean the package would be immediately pulled from the tree?
In this world a package or update would never enter the tree until it 
has been verified to build correctly on all supported platforms.  The 
emphasis is on correctness and true stability, rather than the latest 
version at all cost.
It's a very very different development model to the one that folks in 
this community are used to, and I expect most people on this list will 
disagree with it.  That's fine.  However, if anyone is interested and 
would like to work on it with me, I'd be happy to talk, as like nia I've 
been burned out for a long time trying to keep up with pkgsrc breakage.
--
Jonathan Perkin   -   mnx.io   -   pkgsrc.smartos.org
Open Source Complete Cloud   www.tritondatacenter.com