Gentoo Archives: gentoo-dev

From: "PaweĊ‚ Hajdan
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] making the stable tree more up-to-date
Date: Fri, 16 Dec 2011 13:28:38
Message-Id: 4EEB4742.5000302@gentoo.org
In Reply to: Re: [gentoo-dev] making the stable tree more up-to-date by justin
1 On 12/16/11 11:42 AM, justin wrote:
2 > I really like that you open all those bugs. But it makes no sense to
3 > add arches after a "time out". At least not after a such a short
4 > one.
5
6 I'm sorry this has annoyed/upset you. Let me just point out some facts:
7
8 - in November I first wrote about this new "more stabilizations" thing,
9 and included a list of ~800 packages, including many sci- ones
10 (<http://archives.gentoo.org/gentoo-dev/msg_a8d47428737e600238e3ad3d60f79208.xml>).
11 I don't remember any complains from the sci- maintainers then.
12
13 - people complain that a week-long timeout is too short, while after I
14 CC arches the answer often comes within minutes.
15
16 - actually in this case you've said "go ahead" for the bugs filed (thank
17 you!), so I don't fully understand the concerns here
18
19 - the bugs get filed when a package's most recent version has spent 6
20 months in ~arch, has _no_ open bugs, and is not a beta/alpha/rc/whatever
21 version. Many packages for which I filed bugs spent in ~arch a year or more.
22
23 > The maintainer is responsible for the package, that means it is
24 > their responsibility to decide that a package should go stable.
25
26 Packages with stable versions a year behind suggest this is not always
27 the case. Furthermore, most maintainers are happy about those
28 stabilizations (or tools), and users also like it.
29
30 > In addition they have to make the package fit to the standards that
31 > the arch teams request.
32
33 There are standards and nits. We frequently stabilize a package if only
34 nits are present.
35
36 > So as long as you don't review the packages yourself, consider a
37 > different proceeding than this timeout.
38
39 See the conditions above that packages have to meet to be included in
40 the stabilization list. I consider that an adequate review, and I know
41 arch developers and testers who look at the ebuilds.
42
43 It's always possible to close the bug if the package is deemed not ready.
44
45 > Please remove all added arches from the packages maintained by all
46 > sci* teams.
47
48 I can do that, but are you sure? I noted you've commented "go ahead"
49 on many of those (thank you!) - how about those bugs?

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies