| 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? |
Archives