From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.67) (envelope-from ) id 1IH8KW-0007VS-LS for garchives@archives.gentoo.org; Sat, 04 Aug 2007 01:21:21 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l741KNXp007071; Sat, 4 Aug 2007 01:20:23 GMT Received: from rs25s3.datacenter.cha.cantv.net (rs25s3.datacenter.cha.cantv.net [200.44.33.4]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l741IVLD004750 for ; Sat, 4 Aug 2007 01:18:31 GMT Received: from localhost (dC854664E.dslam-01-3-15-01-1-01.smg.dsl.cantv.net [200.84.102.78]) by rs25s3.datacenter.cha.cantv.net (8.13.8/8.13.0/3.0) with ESMTP id l741IUbZ009947 for ; Fri, 3 Aug 2007 21:18:30 -0400 X-Matched-Lists: [] Received: from localhost ([127.0.0.1]) by localhost with esmtp (Exim 4.67) (envelope-from ) id 1IH8CV-0007Z7-KR for gentoo-dev@lists.gentoo.org; Fri, 03 Aug 2007 21:13:03 -0400 Message-ID: <46B3D29F.5030301@gentoo.org> Date: Fri, 03 Aug 2007 21:13:03 -0400 From: Luis Francisco Araujo User-Agent: Thunderbird 2.0.0.4 (X11/20070709) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Some ideas on how to reduce territoriality References: <1186178767.8470.47.camel@inertia.twi-31o2.org> In-Reply-To: <1186178767.8470.47.camel@inertia.twi-31o2.org> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.1/3682/Mon Jul 16 12:05:30 2007 clamav-milter version 0.91.1 on 10.128.1.88 X-Virus-Status: Clean X-Archives-Salt: a0e43882-54ee-421d-a7a4-86f10a3f5e78 X-Archives-Hash: 87747460fc478d18b0239d6057fd41b7 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Gianelloni wrote: > More and more, I am finding developers who are afraid to touch packages > for even minor things if they're not the maintainer. This is a sad > state of affairs and not the reason we have maintainers. We have > maintainers to assure that a package is being taken care of, not to > establish some kind of "territory" over that package. Because of this > misconception, I would like to come up with and document a listing of > things that any ebuild developer can feel free to do to any package > *without* maintainer consent. These are generally all minor things, but > things that I think are important. I'm going to list off the things > that I can think of, and encourage everyone else to speak up if I've > missed something. > > - HOMEPAGE changes > - LICENSE changes > - arch-specific patches/dependencies - If someone is requesting KEYWORD > changes on a package and it requires a patch or additional dependencies > for your architecture, you are not only permitted, but really are > required to make the necessary changes to add support for your > architecture. I am not sure about this last one ... what if for example this patch is only for supporting a special option of the package for that architecture, but the maintainer of the package found out that such a patch is unnecessary and/or will cause other kind of problems in the package, therefore preferring avoiding such a patch ... or he just wouldn't like to apply the patch for X or Y; or even further, he just wouldn't like to have such a package available for that architecture just yet for Z or W. > - Typo fixes > - SRC_URI changes - If the source has moved, feel free to fix it. We > shouldn't have to wait on the maintainer to fix something this simple. > - *DEPEND changes due to changes in your packages - If a package that > you maintain moves, splits, or otherwise changes in a manner that > requires dependency changes on any other packages in the tree, you > should make those changes yourself. You're free to ask for assistance, > of course, but you have the power to make the changes yourself without > asking permission. After all, you're the one "breaking" the package, so > you should be the one to "fix" it. > - Manifest/digest fixes > - metadata.xml changes > > There's a couple more that I wouldn't mind seeing as things developers > can do without the maintainer, but I can see how these might be a bit > more controversial, so I'm asking for input. > > - Version bumps where the only requirement is to "cp" the ebuild > - (for arch teams) Stabilization of new revisions of an already stable > package - An example of this would be being able to stabilize foo-1.0-r2 > if foo-1.0 (or foo-1.0-r1) is already stable, but not if only foo-0.9 is > stable. > I think these two cases should still be handled by the herd or maintainer of the package. The stabilization idea sounds good and it could free maintainers from filing similar bugs over and over ; but wouldn't this be more and harder work for arch teams?. For example, they should carefully track the history of all the packages to know when and if they should stabilize it yet. > So, what do you guys think? > The other list of things look fine and safe to be changed by any maintainer. Regards, - -- Luis F. Araujo "araujo at gentoo.org" Gentoo Linux -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.5 (GNU/Linux) iD8DBQFGs9KfBCmRZan6aegRAtK7AJ94CDovLQu51QmZy6TW69rMK4Tz1QCgm3C9 tKDsHyNAWsliFCx0MMzcIpA= =RGhM -----END PGP SIGNATURE----- -- gentoo-dev@gentoo.org mailing list