[gentoo-dev] Re: The problem of unmaintained packages in Gentoo

[Duncan]

Kent Fredric posted on Sat, 23 Dec 2017 10:25:51 +1300 as excerpted:

> On Thu, 21 Dec 2017 12:25:11 -0600 William Hubbs <williamh@g.o>
> wrote:
>
>> I think there's some confusion here. I'm not trying to change the bar
>> for ~arch, just trying to understand what that bar is supposed to be.
>
> The bar for ~arch is "end users should have reasonable expectations that
> it mostly works for most purposes, especially those that can be
> trivially checked for by its maintainer"
>
> ~arch will however be imperfect, and there will be issues from time to
> time.
>
> However, the goal is that those issues are not the "easy to find and
> obvious" kind, but the subtle and hard to stumble into.
>
> And I see that as why we have the time interval: Because it gives a good
> opportunity for actual real world usage patterns to discover the sorts
> of problems that you can't discover by actively looking for them,
> the rumsfeldian "unknown unknowns".
>
> Because realistically speaking, ~arch is the stable of tomorrow.
>
> The goal is for it to be stable today.
>
> And when it proves itself ready to be the stable of today, it becomes
> the stable of today.

Very well said. =:^)

I'd simply add a couple points, from a slightly different angle.  They're 
arguably obvious (at least to devs), but equally arguably should be 
explicitly stated to avoid doubt, and certainly clarified things for me 
back in 2004 when I was a new gentooer trying to figure all this stuff 
out.

* Because ~arch is intended to be (as the above says) "the stable of 
tomorrow", with few exceptions it should consist of packages upstream 
already considers stable releases.  As such, the "testing" implied by 
~arch is /Gentoo's/ testing, that is, testing of the ebuild and how it 
interacts with eclasses, profiles and the rest of the Gentoo tree in 
general, /not/ upstream testing.

* The primary exception to the the general rule above is for packages 
where Gentoo /is/ upstream, such that the most obvious method of testing 
the stability of the release (by Gentoo devs functioning as upstream) is 
by releasing it to ~arch, which in this case /is/ upstream's testing.

That isn't to say that where Gentoo is upstream ~arch should be alpha 
quality; the same "obvious bugs should have already been fixed" applies.  
It simply means the quality of ~arch for Gentoo-as-upstream packages may 
be experientially somewhat different, perhaps a bit lower, because in 
that case ~arch is functioning as upstream's testing as well as testing 
of the Gentoo packaging.

This is actually a big reason why I ended up running live-git openrc back 
when I was running it.  Gentoo effectively being upstream and ~arch thus 
being upstream testing, there were occasional breakages with ~arch openrc 
packages, and as a normal ~arch user I found it far easier to trace them 
down when I had full access to the git logs and commit history, as well 
as a finer grain "multiple pre-release snapshots (effectively a snapshot 
each time I upstated), less territory to bisect" testing strategy.

For portage, by contrast, I didn't end up running live-git, because each 
release lists the bugs fixed and I can and do at least review their one-
line summaries every time I update.  Between that and following the 
patches as they're posted for review in portage-dev (so the release-time 
bug list is primarily review), I'm effectively following live-git plus 
reviews anyway, but with the releases as my chosen snapshot frequency.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman