[prev in list] [next in list] [prev in thread] [next in thread]
List: gentoo-dev
Subject: [gentoo-dev] Re: The problem of unmaintained packages in Gentoo
From: Duncan <1i5t5.duncan () cox ! net>
Date: 2017-12-23 4:36:23
Message-ID: pan$ecba7$d56cd520$4ab51457$3e8b9381 () cox ! net
[Download RAW message or body]
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@gentoo.org>
> 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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic