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 <willi...@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
