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

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

> On Aug 5, 2024, at 2:10 PM, Rob Whitlock <rwhitlock22%gmail.com@localhost> wrote:
> 
>> 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.

And right after I sent this, I realized that this would not address the core issue of functioning packages being updated to broken states. So perhaps ignore this suggestion.