| 1 |
foser wrote: [Tue Jun 22 2004, 11:38:32AM EDT] |
| 2 |
> As discussed on IRC, I think this is still overcomplicating the matter. |
| 3 |
> The 'package maintainer' should be responsible for the overall health of |
| 4 |
> a package, not an arch maintainer who just was eager to go stable. |
| 5 |
|
| 6 |
For the most part, I agree with you. I have seen cases where an arch |
| 7 |
jumps ahead for good reasons, but that is not always the case. (And |
| 8 |
when an arch jumps ahead, there should be dialog with the maintainer.) |
| 9 |
|
| 10 |
> The simplest & best solution is just to always wait for the 'maintainers |
| 11 |
> arch' to go stable in normal circumstances, the 'maintainers arch' |
| 12 |
> should be marked as such in the ebuild somehow instead. |
| 13 |
|
| 14 |
You're right. This is actually the same as my proposal for a "stable" |
| 15 |
keyword, just coded differently in the ebuild, and probably saner in |
| 16 |
the long run. In particular it doesn't require sprinkling a new |
| 17 |
keyword into all the ebuilds. We're already most of the way to this |
| 18 |
solution. |
| 19 |
|
| 20 |
Q: How do we mark the maintainer's arch? |
| 21 |
|
| 22 |
A: Make the first arch in KEYWORDS always be the maintainer's arch. |
| 23 |
This is probably the case already in most ebuilds, so there's |
| 24 |
almost no transition involved. |
| 25 |
|
| 26 |
> I think keeping it simple will avoid confusion and always leave the |
| 27 |
> overall package responsibility to the herd, as it should be. |
| 28 |
|
| 29 |
I agree. As mentioned, I think there are exceptions. But they should |
| 30 |
be treated as such, and the general rule should be to following the |
| 31 |
maintainer's lead. |
| 32 |
|
| 33 |
Regards, |
| 34 |
Aron |
| 35 |
|
| 36 |
-- |
| 37 |
Aron Griffis |
| 38 |
Gentoo Linux Developer |
Archives