From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14239 invoked from network); 21 May 2004 15:31:29 +0000 Received: from smtp.gentoo.org (156.56.111.197) by parrot.ussg.indiana.edu with SMTP; 21 May 2004 15:31:29 +0000 Received: from parrot.ussg.indiana.edu ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1BRBzb-0007rY-Ia for arch-gentoo-dev@lists.gentoo.org; Fri, 21 May 2004 15:31:27 +0000 Received: (qmail 28176 invoked by uid 89); 21 May 2004 15:31:27 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 5785 invoked from network); 21 May 2004 15:31:26 +0000 From: Chris Gianelloni Reply-To: wolf31o2@gentoo.org To: Chris Bainbridge Cc: gentoo-dev@lists.gentoo.org In-Reply-To: <200405211554.06946.c.j.bainbridge@ed.ac.uk> References: <200405201846.37173.cbrewer@stealthaccess.net> <1085145580.8753.93.camel@newkid.milsson.nu> <1085146797.25036.52.camel@localhost> <200405211554.06946.c.j.bainbridge@ed.ac.uk> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-8gCHPSM8JajrC7J+wr1M" Organization: Gentoo Linux Message-Id: <1085153967.25140.76.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 21 May 2004 11:39:27 -0400 Subject: Re: [gentoo-dev] Stuff that makes people mad X-Archives-Salt: bcf575c8-100a-4e6c-8298-08b26d75fab3 X-Archives-Hash: 3ecf45436c9777f2c4126aa95543bd5e --=-8gCHPSM8JajrC7J+wr1M Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-05-21 at 10:54, Chris Bainbridge wrote: > One of the things that seems to annoy lots of people is this idea that th= eir=20 > ebuilds are being ignored. I've usually got a bunch (8 at the moment) of=20 > ebuilds in bugs.gentoo waiting to be processed.. the oldest is almost a y= ear=20 > old now. There ought to be some sort of procedure for dealing with user=20 > submitted ebuilds. I would suggest a system of putting them in ~x86 (or=20 > whatever) immediately, and if there are no bug reports for x days move th= em=20 > to x86.=20 If your ebuild is being ignored, it is probably because of one of a few possible reasons. 1. Developers responsible for that area of Gentoo don't see the value of it. While this is sometimes a sad thing to think about, it happens. A good way to solve this is to drum up support for your ebuild. An ebuild submitted to bugzilla with no comments from other users doesn't *appear* to have nearly as much support as an ebuild with lots of comments from users on how they wish this was in portage, and how well it works, etc. 2. Developers responsible for that area of Gentoo don't have the time to maintain another package they don't understand. In a lot of cases, I would say that this is the main factor in an ebuild staying in bugzilla. Once again, a good show of support from users is always a good motivator. Remember that many developers *never* visit the forums or #gentoo, so their only real interface with the users is via bugzilla. 3. Developers are busy working on features which affect many more people and have a much greater demand than your package/ebuild. Unfortunately, this is one you pretty much have to live with, unless of course you want to contribute in the effort to get those features implemented, and therefore give the developers more time to add things like packages and ebuilds to the tree. I am sure there are plenty of other reasons that I am missing, but you start to see the trend. Sometimes simply posting a bug to bugzilla isn't enough to get your package noticed. > All of this could be easily automated... the idea that every package need= s a=20 > maintainer is something that comes from Debian, and is imho unnecessary. = You=20 > end up with a few problems: a limited number of maintainers with limited=20 > package interests and a lack of time to devote, and an alienated develop= er=20 > community who have no way to bug fix or add new ebuilds without going thr= ough=20 > the single developer. When that developers interests shift (as they=20 > invariably do), updates to the package become ignored, and once again the= =20 > developer community can do nothing to fix this as the power rests with th= e=20 > maintainer. As for the idea of *ever* automating any of the additions to ~arch or arch, I quite frankly think it is a horrible idea. There are many ebuild submissions to bugzilla which are very good, and there are just as many that are absolutely appalling. The bad ones can cause some serious damage to not only Gentoo's quality, but possibly even Gentoo's stability. Imagine if someone purposefully added a broken/trojaned package to bugzilla? Imagine if it was glibc? The idea that every package needs a maintainer has little to do with Debian, and more to do with the fact that having accountability in one's actions tends to leave people more honest. It also tends to improve quality, since the person who added the ebuild will be held accountable for what the ebuild does to a user's system. The solution to the "single developer" problem is the Gentoo herd system. There are usually multiple developers responsible for a single ebuild/set of ebuilds, rather than a single person. Given that Gentoo will never have an automated ebuild submission system, how does having a single developer decide to no longer maintain a package become any worse than a user submitting an ebuild, it being added, with no maintainer, mind you, as you would want, then the user dropping off the face of the planet. Either way you are left with an unmaintained ebuild, which lowers the quality, and possibly even the security of our distribution as a whole. After all, what if the unmaintained package has a security flaw in it that goes unnoticed? The difference between a package having a Gentoo maintainer or not is that with a Gentoo maintainer, the chances of something being unmaintained are much less than simply accepting any ebuild from anywhere and not having a dedicated maintainer. Usually, when a developer leaves, devrel and others try to find a new maintainer for that developer's packages. If it ends up being a long-term problem, we decide on whether or not the package should remain in the portage tree.=20 There have been cases where a package was *not* removed simply because there were users out there submitting fixed ebuilds for newer version, etc to bugzilla. Once again, active participation helps much more with Gentoo than any amount of talk. When users ask, we listen. The more users that request something, the greater the chances of us doing it. It all boils down to there being only a limited number of developers and a limited number of hours in the day. We have to prioritize. A flaw in kde-libs is probably going to get higher priority than an ebuild for a new lm-sensors front-end for XFCE, simply due to the numbers affected. > There is no need to be defensive and start saying things like "if you don= 't=20 > like it this way then fork away.." when the desire of the complainer is t= o=20 > improve gentoo, not start/join another project. I completely understand, and as I stated before, drum up some support for the things you request and you'll get a lot farther in your quests to improve Gentoo. --=20 Chris Gianelloni Developer Games/LiveCD Teams Gentoo Linux Is your power animal a penguin? --=-8gCHPSM8JajrC7J+wr1M Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBAriKvkT4lNIS36YERAle3AKDDDwGmfZIyA8CXlaMcTNJgbPaShQCdFkhO UGTtIQTPDuzfNn9LoGQvCm0= =xxp9 -----END PGP SIGNATURE----- --=-8gCHPSM8JajrC7J+wr1M--