Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: Policy for late/slow stabilizations
Date: Mon, 28 Jun 2010 09:21:57
Message-Id: pan.2010.06.28.09.21.16@cox.net
In Reply to: Re: [gentoo-dev] Policy for late/slow stabilizations by Ciaran McCreesh
1 Ciaran McCreesh posted on Sun, 27 Jun 2010 18:43:30 +0100 as excerpted:
2
3 > On Sun, 27 Jun 2010 20:22:33 +0300
4 > Markos Chandras <hwoarang@g.o> wrote:
5 >> > Which does Gentoo care about more: slightly increased convenience for
6 >> > most developers, or considerably increased inconvenience for users of
7 >> > minority archs?
8 >> >
9 >> I don't follow you. Increased convenience just for the devs? How?
10 >
11 > Not having to keep old versions around for a few archs is slightly more
12 > convenient for most people.
13 >
14 > Having to deal with dropped keywords is a huge inconvenience for users
15 > on minority archs.
16
17 As already stated on the other sub-threads, that's not the point at all.
18 Rather, it's a simple matter of letting an arch's stable tree dynamically
19 and realistically adjust to the level of arch support they have. If the
20 stable set gets small enough, it's probably time to officially reduce the
21 arch status to testing tree support only, not security supported, etc.
22 But well before that point, it's likely a core package set can be
23 maintained at stable, with perhaps certain arch-usage specific area stable
24 support as well, while still being unrealistic to try to keep a stable
25 version of (nearly) all at-one-point-known-to-work packages available.
26
27 If the arch support simply isn't there, it really is better to have that
28 reflected in the size of the stable set, such that users actually know
29 that and know what's being actively supported on their arch and what
30 isn't, than to try to fake it, which is what's going on now. It's not a
31 question of more convenience vs less, but of having arch keyword status
32 reflect arch support reality.
33
34 That said, if there's not already a simple way to get the info out of VCS
35 (perhaps there is, I don't know), archs may wish to maintain a list of
36 packages and versions that once were stable, along with comments on
37 specific destabilization reason (it didn't work with gcc-vX on that arch,
38 for instance) if known, so it'll be somewhat easier to expand stable
39 coverage again if we happen to pickup a few new devs with a strong
40 interest in the arch.
41
42 --
43 Duncan - List replies preferred. No HTML msgs.
44 "Every nonfree program has a lord, a master --
45 and if you use the program, he is your master." Richard Stallman