From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
Date: Fri, 28 Jul 2017 21:45:57 +0000 (UTC) [thread overview]
Message-ID: <pan$c0f27$f2e2908c$edc0af56$c419b383@cox.net> (raw)
In-Reply-To: assp.0382565697.20170728161042.22082063@o-sinc.com
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
next prev parent reply other threads:[~2017-07-28 21:46 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-24 21:22 [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts? Sergei Trofimovich
2017-07-24 21:52 ` [gentoo-dev] " Pacho Ramos
2017-07-24 23:22 ` [gentoo-dev] " Peter Stuge
2017-07-24 23:52 ` Rich Freeman
2017-07-25 4:34 ` [gentoo-dev] " Duncan
2017-07-25 6:26 ` Hans de Graaff
2017-07-25 6:18 ` [gentoo-dev] " Hans de Graaff
2017-07-25 9:18 ` Pacho Ramos
2017-07-25 11:54 ` Michał Górny
2017-07-25 12:15 ` Pacho Ramos
2017-07-25 13:19 ` Michał Górny
2017-07-25 13:23 ` Pacho Ramos
2017-07-25 11:26 ` Rich Freeman
2017-07-25 7:44 ` Sergei Trofimovich
2017-07-28 10:44 ` Andreas K. Huettel
2017-07-28 12:45 ` Marek Szuba
2017-07-28 13:10 ` Sam Jorna (wraeth)
2017-07-28 19:59 ` William L. Thomson Jr.
2017-07-28 21:21 ` David Seifert
2017-07-31 0:28 ` Sam Jorna
2017-07-31 0:40 ` Benda Xu
2017-07-31 2:44 ` William L. Thomson Jr.
2017-07-31 2:56 ` Sam Jorna
2017-07-31 15:00 ` William L. Thomson Jr.
2017-07-31 12:59 ` Andreas K. Huettel
2017-07-31 14:43 ` William L. Thomson Jr.
2017-07-31 14:47 ` David Seifert
2017-07-28 19:44 ` Alec Warner
2017-07-29 1:05 ` Rich Freeman
2017-07-31 14:52 ` Alec Warner
2017-07-31 15:11 ` Rich Freeman
2017-07-31 16:51 ` Peter Volkov
2017-08-01 0:24 ` [gentoo-dev] " Duncan
2017-08-01 0:55 ` Rich Freeman
2017-08-01 1:45 ` Duncan
2017-07-31 16:44 ` [gentoo-dev] " Michał Górny
2017-07-29 4:18 ` Daniel Campbell
2017-07-29 16:41 ` Mart Raudsepp
2017-07-29 19:10 ` David Seifert
2017-07-29 18:03 ` Andrew Savchenko
2017-07-25 7:22 ` Dirkjan Ochtman
2017-07-25 13:10 ` [gentoo-dev] " Michael Palimaka
2017-07-25 13:22 ` Rich Freeman
2017-07-25 20:16 ` Daniel Campbell
2017-07-25 13:36 ` Pacho Ramos
2017-07-25 14:15 ` Peter Stuge
2017-07-29 18:08 ` [gentoo-dev] " Christopher Head
2017-07-31 6:49 ` R0b0t1
2017-07-25 9:03 ` [gentoo-dev] " Agostino Sarubbo
2017-07-25 19:45 ` Markus Meier
2017-07-25 20:12 ` Rich Freeman
2017-07-26 5:49 ` Hans de Graaff
2017-07-25 12:59 ` Michael Palimaka
2017-07-25 13:30 ` Pacho Ramos
2017-07-25 13:51 ` Michał Górny
2017-07-25 14:13 ` [gentoo-dev] " Michał Górny
2017-07-25 14:28 ` Rich Freeman
2017-07-27 23:12 ` Denis Dupeyron
2017-07-27 23:41 ` Rich Freeman
2017-07-28 0:03 ` Denis Dupeyron
2017-07-28 21:24 ` William Hubbs
2017-07-29 10:24 ` Andrew Savchenko
2017-07-28 20:10 ` William L. Thomson Jr.
2017-07-28 21:12 ` A. Wilcox
2017-07-28 21:41 ` William L. Thomson Jr.
2017-07-29 13:41 ` Andreas K. Huettel
2017-07-28 21:45 ` Duncan [this message]
2017-07-28 21:56 ` [gentoo-dev] " William L. Thomson Jr.
2017-07-29 19:44 ` Walter Dnes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$c0f27$f2e2908c$edc0af56$c419b383@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox