1 |
Hi guys, |
2 |
|
3 |
I've read through most of these arches vs. maintainers threads. It |
4 |
sounds like Carsten hits the nail on the head with this paragraph: |
5 |
|
6 |
But isn't exactly this an issue? You don't know which arch the |
7 |
package maintainer is using and checking against a single arch |
8 |
doesn't work, because a maintainer could mark it stable on his |
9 |
arch for some reason before the package maintainer had done this? |
10 |
So the first arch maintainer goes ahead, the next one thinks "oh, |
11 |
seems like the package maintainer marked it stable", gets bitten |
12 |
and the package maintainer has to resolve resulting problems |
13 |
(possibly including blame by users)? |
14 |
|
15 |
So let's use one more KEYWORD: stable. This KEYWORD would be set by |
16 |
the package maintainer to indicate her impression of what versions |
17 |
should be considered stable. This would have the following effects: |
18 |
|
19 |
1. Repoman could check keyword changes, warning arch maintainers |
20 |
when they mark a version arch-stable that is not marked stable |
21 |
by the maintainer. |
22 |
|
23 |
2. Bugs can be assigned appropriately: |
24 |
|
25 |
stable -- assign maintainer, cc arch team |
26 |
not stable, arch -- assign arch team, cc maintainer |
27 |
not stable, ~arch -- assign maintainer, cc arch team |
28 |
|
29 |
This makes it clear that arches that choose to move ahead of the |
30 |
maintainer get to deal with the bugs until the maintainer "catches |
31 |
up". |
32 |
|
33 |
Thoughts? |
34 |
|
35 |
Regards, |
36 |
Aron |
37 |
|
38 |
-- |
39 |
Aron Griffis |
40 |
Gentoo Linux Developer |