Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: rfc: revisiting our stabilization policy
Date: Sun, 26 Jan 2014 22:57:06
Message-Id: pan$d1bf2$395b550e$221c2d1c$
In Reply to: Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy by Rich Freeman
1 Rich Freeman posted on Sat, 25 Jan 2014 19:59:19 -0500 as excerpted:
3 > On Fri, Jan 24, 2014 at 11:02 PM, Duncan <1i5t5.duncan@×××.net> wrote:
4 >> I've often wondered just how much faster gentoo could move, and how
5 >> much better we could keep up with upstream, if we weren't so focused on
6 >> 30+day outdated stab?le bumping all the time. All that effort... from
7 >> my viewpoint going to waste on something that gentoo really isn't going
8 >> to be that great at anyway, certainly in comparison to other distros
9 >> which REALLY provide a stab?le service, up to a /decade/ outdated,
10 >> supporting often trailing edge software, in an effort to slow down
11 >> progress for people that don't want to move so fast.
12 >
13 > I get what you're saying, and I'm going to use a bit of hyperbole so
14 > don't take this too seriously, but couldn't you just as easily argue
15 > that Gentoo could go much faster if we actually took advantage of the
16 > fact that we DO have a stable tree, and stop being so careful about not
17 > breaking the testing tree?
19 If that was hyperbole it was a bit too subtle for me. =:^)
21 Actually, I'd support something like this too. After all, I've already
22 stated that on some packages I run from the project overlay and/or the
23 live-vcs version. In a way, that's arguably what testing should /be/,
24 tho it'd certainly be a departure from how gentoo handles things now.
26 Basically in my ideal gentoo, what's now stable would disappear entirely,
27 and what's now testing would be the new stable, with what's now hard-
28 masked and/or only available in the overlays being testing.
30 But obviously I recognize that's totally broken for a lot of people who
31 do depend on gentoo stable, and as such, I don't really consider it an
32 entirely practical option... But it'd be nice for me anyway! =:^)
34 So it's far from hyperbole in my world. In my world it's the ideal. =:^)
36 > Honestly, I think both trees represent a pretty decent balance. It is
37 > pretty safe to run ~arch for the packages you really are interested in,
38 > and run stable for the stuff that you don't care so much about, thus
39 > limiting your exposure to problems while getting cutting-edge where you
40 > care for it.
42 Except, well, ~arch is if anything safe enough to be stable, and
43 unfortunately, isn't always that cutting edge after all. One has to run
44 overlays and hard-unmask live-vcs versions to actually get cutting edge
45 testing, which is in my view... unfortunate.
47 > Most of the concern in this thread has been about some minor archs that
48 > struggle to keep up. It seems like the simplest solution in these cases
49 > is to just have them focus on @system packages for the stable tree, and
50 > let users deal with more breakage outside of that set (where it isn't
51 > super-disruptive). If you're running a minor arch chances are that
52 > you're happy to have any support at all, since you sure aren't going to
53 > be running Ubuntu...
55 Agreed.
57 Tho AFAIK both Ubuntu and Fedora have an arm variants... But also AFAIK,
58 due to them being binary distros these variants are closer to the sub-arm-
59 keyword-variants I believe someone else proposed in this thread (??) for
60 gentoo/arm as well, consequently leaving other sub-arch-variants that
61 gentoo/arm supports out in the cold.
63 --
64 Duncan - List replies preferred. No HTML msgs.
65 "Every nonfree program has a lord, a master --
66 and if you use the program, he is your master." Richard Stallman


Subject Author
[gentoo-dev] Re: rfc: revisiting our stabilization policy Duncan <1i5t5.duncan@×××.net>