| 1 |
On Tue, 2004-06-22 at 10:44 -0400, Aron Griffis wrote: |
| 2 |
> So let's use one more KEYWORD: stable. This KEYWORD would be set by |
| 3 |
> the package maintainer to indicate her impression of what versions |
| 4 |
> should be considered stable. This would have the following effects: |
| 5 |
> |
| 6 |
> 1. Repoman could check keyword changes, warning arch maintainers |
| 7 |
> when they mark a version arch-stable that is not marked stable |
| 8 |
> by the maintainer. |
| 9 |
> |
| 10 |
> 2. Bugs can be assigned appropriately: |
| 11 |
> |
| 12 |
> stable -- assign maintainer, cc arch team |
| 13 |
> not stable, arch -- assign arch team, cc maintainer |
| 14 |
> not stable, ~arch -- assign maintainer, cc arch team |
| 15 |
> |
| 16 |
> This makes it clear that arches that choose to move ahead of the |
| 17 |
> maintainer get to deal with the bugs until the maintainer "catches |
| 18 |
> up". |
| 19 |
|
| 20 |
As discussed on IRC, I think this is still overcomplicating the matter. |
| 21 |
The 'package maintainer' should be responsible for the overall health of |
| 22 |
a package, not an arch maintainer who just was eager to go stable. |
| 23 |
The simplest & best solution is just to always wait for the 'maintainers |
| 24 |
arch' to go stable in normal circumstances, the 'maintainers arch' |
| 25 |
should be marked as such in the ebuild somehow instead. I think keeping |
| 26 |
it simple will avoid confusion and always leave the overall package |
| 27 |
responsibility to the herd, as it should be. |
| 28 |
|
| 29 |
- foser |
Archives