1 |
On Mon, 17 Nov 2008 10:10:57 -0500 |
2 |
Daniel Gryniewicz <dang@g.o> wrote: |
3 |
|
4 |
> On Sun, 2008-11-16 at 18:38 -0600, Ryan Hill wrote: |
5 |
> |
6 |
> <snip> |
7 |
> |
8 |
> > The maintainer MUST NOT NEVER EVER NOT EVEN A LITTLE BIT remove the |
9 |
> > latest stable ebuild of an arch without the approval of the arch |
10 |
> > team or he/she will be fed to the Galrog. |
11 |
> |
12 |
> As long as the maintainer can pass off the maintenance of the |
13 |
> (sometimes dozens) of ancient ebuilds that need to be kept around for |
14 |
> that one arch to the arch team, and re-assign any resulting bugs to |
15 |
> them, fine. |
16 |
|
17 |
Since when do we maintain ancient ebuilds kept around for an arch |
18 |
team now? Drop the other keywords and get on with your life. |
19 |
|
20 |
> Or, alternatively, unilaterally decide to drop all |
21 |
> keywords for the arch in question. |
22 |
> |
23 |
> Yes, that was extreme, but no more than the previous quoted statement. |
24 |
|
25 |
You sir, have an appointment with the Galrog. |
26 |
|
27 |
> There needs to be give and take here. Yes, it's really bad to remove |
28 |
> the last stable ebuild for an arch. However, its *also* bad to have |
29 |
> to maintain years old versions of lots of ebuilds. And yes, it will |
30 |
> be a lot, since most packages don't exist in a vacuum, and require |
31 |
> older deps (which possibly will be maintained by other maintainers |
32 |
> than the first package, causing a cascade of old packages in the |
33 |
> tree). |
34 |
> |
35 |
> All this will do in practice is cause maintainers to ignore bugs for |
36 |
> those old packages for those few arches, since the maintainer won't |
37 |
> have that version installed. In fact, in my experience, they |
38 |
> frequently *can't* have that version installed, since it requires |
39 |
> older versions of other packages that need to be upgraded to maintain |
40 |
> newer versions of the same package. |
41 |
> |
42 |
> How much bit rot do we want in the tree? |
43 |
> |
44 |
> Daniel (who is both an arch team member and gnome team lead) |
45 |
|
46 |
Did you not read the first part of the suggestion? |
47 |
|
48 |
- maintainer files a stabilization request. |
49 |
- arch testers do their thing |
50 |
- arch teams gradually mark ebuild stable |
51 |
- maintainer pokes arm, sh, mips, ppc (only an example, relax) |
52 |
- mips reminds maintainer there is no stable mips keyword |
53 |
- ppc stables |
54 |
- maintainer waits |
55 |
- maintainer pokes arm, sh |
56 |
- maintainer waits |
57 |
- maintainer marks stable on arm, sh |
58 |
- maintainer removes ancient stable ebuilds that maintainer doesn't |
59 |
want to maintain anymore because everyone has a nice new stable |
60 |
ebuild. |
61 |
- maintainer goes out for a frosty beverage |
62 |
|
63 |
|
64 |
the idea is that arch teams are around to help the maintainer test on |
65 |
architectures the maintainer doesn't have. if the arch teams are |
66 |
unable or unwilling to help at the moment, that should not stop the |
67 |
maintainer from maintaining. |
68 |
|
69 |
also keep in mind that this only occurs after the arch teams have ample |
70 |
time to interject (which is why i suggested 90 days). if an arch team |
71 |
can't comment on a bug in 3 months (a simple "i'd rather this not go |
72 |
stable until i can test it further" should be enough) then they have |
73 |
IMO lost their opportunity to matter. |
74 |
|
75 |
|
76 |
-- |
77 |
gcc-porting, by design, by neglect |
78 |
treecleaner, for a fact or just for effect |
79 |
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |