[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Duncan]

William L. Thomson Jr. posted on Fri, 28 Jul 2017 16:10:42 -0400 as
excerpted:

> It seems odd that upstream will release a package. Just for downstream
> to consider it not stable. Did it get messed up during packaging? Did it
> get messed up by the distro? The whole lag thing does not make sense for
> Gentoo. Sooner released and tested on Gentoo. Sooner bugs can be
> founded, reported back to upstream, etc. Speeds up development. That is
> Gentoo's role in FOSS IMHO.

Not so odd.  Gentoo's arch-stable has a different meaning than upstream's 
stable.  As a long time gentooer I'm surprised you weren't aware of this 
already.

In general (individual packages may differ somewhat on a case-by-case 
basis, one variant being packages where gentoo /is/ upstream and ~arch is 
thus used for upstream unstable testing to some degree)...

Gentoo's stable doesn't really relate to upstream stable except that 
upstream betas and the like (well, short-term ones, not the ones that 
last years without a non-beta release...) aren't normally considered 
stable candidates because they're not released by upstream as such.  
Instead, gentoo's stable means that the packaging -- the ebuild script, 
the eclasses it calls, and the eapi as encoded in pms and deployed by the 
pm -- is considered tested and stable on a particular arch.  Gentoo-
stable also includes proper integration, making sure the header files, 
libs, configuration, documentation, etc, all end up in the place gentooers 
expect them to be, that they build with our particular toolset, etc.

Similarly, upstream-unstable isn't supposed to be a candidate for ~arch 
either, because ~arch is supposed to be upstream stable that simply 
hasn't yet had enough testing of its gentoo packaging and integration in 
ordered for that particular package to be declared stable.

That's one reason why ~arch normally works so well for those prepared to 
manually deal with the occasional packaging or integration hiccup, missed 
or incorrect dependency, failed merge due to conflict with existing files 
because upstream moved something and the package hasn't yet adapted to 
it, etc -- it's releases that upstream has already declared reasonably 
stable, that simply aren't yet sufficiently tested in terms of the gentoo 
packaging and integration, and if a user's willing to deal with the 
occasional hiccup there it should otherwise be as stable as the upstream 
declaration.

Which is why people like me find ~arch quite stable -- it /should/ be for 
us, as it's upstream stable, and we're prepared to deal with the minor 
dependency and integration issues, etc, that the process of gentoo 
stabilization is intended to fix.

The problem this thread is seeking to at least incrementally tweak toward 
the better is that the above only works for people on stable, when people 
actually declare a package stable when there's no serious bugs left after 
the testing period.  Sometimes they forget, packages drop thru the 
cracks, etc, and stable users get further behind than they would be if 
policies were actually being followed.

And perhaps more to the point, on the minor archs which tend to be the 
bottleneck, sometimes there's simply not the resources, either 
sufficiently interested people with the time (who are volunteers after 
all, so interest and time can't be commanded) or arch hardware or both, 
available to do those stabilizations.  The proposal here hopes to 
automate much of the process as well as standardize it, hopefully 
alleviating that bottleneck.

Tho as I've said before, as one who /is/ prepared to deal with the 
occasional packaging or integration issue and thus finds ~arch perfectly 
usable, I'd personally have no problem with dropping stable, it's just 
that I know it to be a practical impossibility, because were we to do so, 
instead of freeing that time to work on what's now ~arch, we'd simply 
lose most of the volunteers who have a major interest in stable.

-- 
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