On Tue, 18 Nov 2008 11:57:23 -0500 Daniel Gryniewicz <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-11-17 at 19:08 -0600, Ryan Hill wrote: > > On Mon, 17 Nov 2008 10:10:57 -0500 > > Daniel Gryniewicz <[EMAIL PROTECTED]> wrote: > > > > > On Sun, 2008-11-16 at 18:38 -0600, Ryan Hill wrote: > > > > > > <snip> > > > > > > > The maintainer MUST NOT NEVER EVER NOT EVEN A LITTLE BIT remove > > > > the latest stable ebuild of an arch without the approval of the > > > > arch team or he/she will be fed to the Galrog. > > > > > > As long as the maintainer can pass off the maintenance of the > > > (sometimes dozens) of ancient ebuilds that need to be kept around > > > for that one arch to the arch team, and re-assign any resulting > > > bugs to them, fine. > > > > Since when do we maintain ancient ebuilds kept around for an arch > > team now? Drop the other keywords and get on with your life. > > Since forever, at least in my experience. See below. > > > > > Did you not read the first part of the suggestion? > > Yes. I was not objecting to this sequence. I was objecting to the > "MUST NOT NEVER EVER NOT EVEN A LITTLE BIT" part. > > > > > - maintainer files a stabilization request. > > - arch testers do their thing > > - arch teams gradually mark ebuild stable > > - maintainer pokes arm, sh, mips, ppc (only an example, relax) > > - mips reminds maintainer there is no stable mips keyword > > - ppc stables > > - maintainer waits > > - maintainer pokes arm, sh > > - maintainer waits > > - maintainer marks stable on arm, sh > > - maintainer removes ancient stable ebuilds that maintainer doesn't > > want to maintain anymore because everyone has a nice new stable > > ebuild. > > - maintainer goes out for a frosty beverage > > - Arch team comes back and says the new version doesn't work. > - Maintainer is stuck maintaining the old version *forever*, at least > potentially. See, here's your problem. If the arch team has issues and needs an old ebuild, the arch team is effectively the maintainer of that ebuild. Drop the other keywords if you like, and forget it exists. > Concrete example. Gnome was keyworded on an arch. A new version of > gnome came out that needed hal. Hal did not work on said arch. For a > long long time, we had to keep a very old version of gnome in the > tree, just for that arch. This was a maintenance burden. Gnome is > not just one or 2 packages. So you would rather have the ability to just drop the keywords on this arch and leave them and their gnome users up the creek? > > the idea is that arch teams are around to help the maintainer test > > on architectures the maintainer doesn't have. if the arch teams are > > unable or unwilling to help at the moment, that should not stop the > > maintainer from maintaining. > > > > also keep in mind that this only occurs after the arch teams have > > ample time to interject (which is why i suggested 90 days). if an > > arch team can't comment on a bug in 3 months (a simple "i'd rather > > this not go stable until i can test it further" should be enough) > > then they have IMO lost their opportunity to matter. > > This is not about arches just being slackers. This is about arches > denying stable (or even ~) for some reason. If I cannot drop an old > version of something just because the new version doesn't (and won't) > work on an arch, that's really bad for me. I know I've been oversimplifying things thus far, and I understand this is a real problem for you. However, I believe that as bad as it is for you, dumping the problem on the user is the greater evil. And yes, this is not an attempt to solve everything - it is directly aimed at the slacker problem, which i think is the biggest part of the issue. Other problems will need other solutions. In any case, if you still think it's unworkable and dropping keywords is the correct solution, I won't continue pushing it. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
