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

[Rob Whitlock <rwhitlock22%gmail.com@localhost>]

> On Aug 5, 2024, at 1:57 PM, J. Lewis Muir <jlmuir%imca-cat.org@localhost> wrote:
> 
> On 07/15, Jonathan Perkin wrote:
>> 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.
> 
> Late to the party, but sounds like something I'd really like!
> 
> How would it affect new packages or package bug fixes on such a
> Sun/illumos-development-model branch?  My use case is typically the
> following: I'd like to follow a stable branch because I don't want to
> deal with software changing/breaking all the time.  I either (1) go to
> install a new package and find that it's not available in the stable
> branch, or (2) install a package but find that it crashes or doesn't
> work.  Then I want to add the new package or fix the existing package.
> I'd wish to not have to try or fix the same package in the current
> branch because that means doing the same work twice (i.e., maintaining
> a stable branch and current branch source tree and changing, building,
> etc. in both, which means doing all the work twice).  I really wish I
> could eliminate this double work situation.  I also get the feeling from
> the pkgsrc developers that work on a stable branch is less desirable
> and that new packages and fixes need to be done on the current branch.
> I know that what you describe is based on whether packages build
> successfully, and I think that's very good, but then my usage experience
> usually comes up, which isn't covered by that, and I'm wondering how
> that would work with the Sun/illumos-development model.

I've been wondering about this too. Maybe instead of an entirely separate tree it would be better to

1) have a way to mark packages according to how much they have been tested
2) have a way to browse only packages that have been marked as having a certain level of testing

(1) could be as simple as a Makefile variable, but I'm not sure how (2) would be implemented without having the build system run through all the pkgsrc Makefiles whenever such a list was to be browsed.