Gentoo Archives: gentoo-dev

From: Steev Klimaszewski <steev@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
Date: Mon, 27 Jan 2014 07:41:42
In Reply to: Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy by Rich Freeman
1 On Sun, 2014-01-26 at 16:35 -0500, Rich Freeman wrote:
2 > On Sun, Jan 26, 2014 at 1:56 PM, Peter Stuge <peter@×××××.se> wrote:
3 > >
4 > > I don't think that's "completely optional" though, it sounds like a
5 > > one-way function. If have ever stabilized a package once then must
6 > > ensure a stable package forever.
7 > >
8 > > I think arbitrarily removing stable versions should also be an option,
9 > > and I think package managers would be able to deal with that without
10 > > much extra effort?
11 >
12 > Well, I think we certainly should be able to de-stabilize packages.
13 > I've seen this happen in the past, especially when the need to not be
14 > stable is inherent in the package itself (such as game clients that
15 > need to be synchronized with servers - only one version will ever work
16 > at any time buggy or not).
17 >
18 > Ideally this should really be the result of communication between the
19 > maintainer and arch team. What we definitely don't want is a package
20 > that gets stabilized, and then six months later the whole package is
21 > back at ~arch, and then six months later there is a stable version
22 > again, and so on. That just isn't, well, stable.
23 >
24 > However, if an arch team is feeling overwhelmed I'd strongly encourage
25 > them to put out a bulletin telling maintainers to stop STABLEREQs for
26 > non-system packages, or whatever other guidance they want to issue.
27 > It has been pointed out that on these archs system packages often
28 > don't work, so having those be stable at least lets them target
29 > versions they want to fix up and lets users get a bootable system
30 > without too much fuss. Falling back to a defensible position and all
31 > that...
32 >
34 It's not necessarily the STABLEREQs stopping, some of the issues are (at
35 least on some arches!) that some of the unstable software doesn't quite
36 work properly anymore, and we are failing at communicating. And in
37 those cases, we on the arch teams should definitely be pointing this
38 out, and filing bugs so that the issues can be sorted.
40 > But, nobody needs anybody's permission to do any of this. Ideally the
41 > arch team should take the leadership to establish a policy on their
42 > arch which is maintainable. If they don't do that, well, then
43 > maintainers complain and we get threads like this one. The arch team
44 > has the greatest interest in having the arch work - I'd strongly
45 > support them in creating any policy for their arch that they can
46 > follow-through on.
47 >
48 > Rich
49 >


Subject Author
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy Rich Freeman <rich0@g.o>