From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1L2TtL-0004B8-Ad for garchives@archives.gentoo.org; Tue, 18 Nov 2008 16:57:31 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7C84EE049D; Tue, 18 Nov 2008 16:57:29 +0000 (UTC) Received: from apollo.fprintf.net (apollo.fprintf.net [208.75.87.34]) by pigeon.gentoo.org (Postfix) with ESMTP id 1860CE049D for ; Tue, 18 Nov 2008 16:57:27 +0000 (UTC) Received: (qmail 27345 invoked from network); 18 Nov 2008 16:57:25 -0000 Received: from unknown (HELO ?10.68.253.67?) (dang@fprintf.net@69.198.118.194) by apollo.fprintf.net with ESMTPA; 18 Nov 2008 16:57:25 -0000 Subject: Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds From: Daniel Gryniewicz To: gentoo-dev@lists.gentoo.org In-Reply-To: <20081117190806.3ffe2dbb@halo.dirtyepic.sk.ca> References: <20081110181334.GD7038@aerie.halcy0n.com> <20081116183814.0931c9de@halo.dirtyepic.sk.ca> <1226934657.4891.21.camel@athena.ghs.com> <20081117190806.3ffe2dbb@halo.dirtyepic.sk.ca> Content-Type: text/plain Date: Tue, 18 Nov 2008 11:57:23 -0500 Message-Id: <1227027443.4891.54.camel@athena.ghs.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.24.1.1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 83fd5556-2ea4-4ee6-8577-7aff79ff6de2 X-Archives-Hash: dd38c9f5a31a585ce9493b3f85eb6ed1 On Mon, 2008-11-17 at 19:08 -0600, Ryan Hill wrote: > On Mon, 17 Nov 2008 10:10:57 -0500 > Daniel Gryniewicz wrote: > > > On Sun, 2008-11-16 at 18:38 -0600, Ryan Hill wrote: > > > > > > > > > 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. 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. > > 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. Daniel