1 |
On 12/16/11 2:27 PM, "Paweł Hajdan, Jr." wrote: |
2 |
> On 12/16/11 11:42 AM, justin wrote: |
3 |
>> I really like that you open all those bugs. But it makes no sense to |
4 |
>> add arches after a "time out". At least not after a such a short |
5 |
>> one. |
6 |
> |
7 |
> I'm sorry this has annoyed/upset you. Let me just point out some facts: |
8 |
> |
9 |
> - in November I first wrote about this new "more stabilizations" thing, |
10 |
> and included a list of ~800 packages, including many sci- ones |
11 |
> (<http://archives.gentoo.org/gentoo-dev/msg_a8d47428737e600238e3ad3d60f79208.xml>). |
12 |
> I don't remember any complains from the sci- maintainers then. |
13 |
> |
14 |
> - people complain that a week-long timeout is too short, while after I |
15 |
> CC arches the answer often comes within minutes. |
16 |
> |
17 |
> - actually in this case you've said "go ahead" for the bugs filed (thank |
18 |
> you!), so I don't fully understand the concerns here |
19 |
> |
20 |
> - the bugs get filed when a package's most recent version has spent 6 |
21 |
> months in ~arch, has _no_ open bugs, and is not a beta/alpha/rc/whatever |
22 |
> version. Many packages for which I filed bugs spent in ~arch a year or more. |
23 |
> |
24 |
>> The maintainer is responsible for the package, that means it is |
25 |
>> their responsibility to decide that a package should go stable. |
26 |
> |
27 |
> Packages with stable versions a year behind suggest this is not always |
28 |
> the case. Furthermore, most maintainers are happy about those |
29 |
> stabilizations (or tools), and users also like it. |
30 |
> |
31 |
>> In addition they have to make the package fit to the standards that |
32 |
>> the arch teams request. |
33 |
> |
34 |
> There are standards and nits. We frequently stabilize a package if only |
35 |
> nits are present. |
36 |
> |
37 |
>> So as long as you don't review the packages yourself, consider a |
38 |
>> different proceeding than this timeout. |
39 |
> |
40 |
> See the conditions above that packages have to meet to be included in |
41 |
> the stabilization list. I consider that an adequate review, and I know |
42 |
> arch developers and testers who look at the ebuilds. |
43 |
> |
44 |
> It's always possible to close the bug if the package is deemed not ready. |
45 |
> |
46 |
>> Please remove all added arches from the packages maintained by all |
47 |
>> sci* teams. |
48 |
> |
49 |
> I can do that, but are you sure? I noted you've commented "go ahead" |
50 |
> on many of those (thank you!) - how about those bugs? |
51 |
> |
52 |
|
53 |
I really, really appreciate this push you give towards more stable trees |
54 |
and I don't think sci teams dislike this. The only thing I want is some |
55 |
time to review the packages before I sent them to the arch teams. And as |
56 |
I said before, it would have been better if I would have dropped a short |
57 |
comment on the bugs telling that they are in progress. |
58 |
|
59 |
The recent "go aheads" were simply that I found time to review the one |
60 |
or other bug. |
61 |
|
62 |
So lets agree that your proceeding is worth the effort, but extend the |
63 |
time you give the maintainer to iron their packages. |
64 |
|
65 |
justin |