From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7930 invoked by uid 1002); 15 Jul 2003 12:01:44 -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 21898 invoked from network); 15 Jul 2003 12:01:44 -0000 From: Paul de Vrieze To: gentoo-dev@gentoo.org Date: Tue, 15 Jul 2003 14:01:40 +0200 User-Agent: KMail/1.5.2 References: <03d901c34ac5$d249a3c0$c200a8c0@Churchill> In-Reply-To: <03d901c34ac5$d249a3c0$c200a8c0@Churchill> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_k0+E/DhPz5IVgQy"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200307151401.40556.pauldv@gentoo.org> X-Spam-Status: No, hits=-5.7 required=5.0 X-Spam-Level: X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Subject: Re: [gentoo-dev] Gentoo part II. X-Archives-Salt: 68c7c272-4e5f-4df2-89a0-deb3dd31dec0 X-Archives-Hash: 1b0febbae0a60e873469f1208f177733 --Boundary-02=_k0+E/DhPz5IVgQy Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Tuesday 15 July 2003 13:39, Stuart Herbert wrote: > > I hope you realise that your desires are conflicting. more > > ebuilds leads to > > more unmaintained ebuilds. More QA needs more time. > > Rubbish. Totally utter rubbish. > > The right levels of QA *save* time, because things are done > as-right-as-they-can-be first time. Instead of time going into bug fixing > and constantly re-doing what has been done, the time instead goes into > moving forward, and doing new things. *Too much* QA just bogs the whole > thing down, and makes it impossible to get anything done in a timely > fashion. The two are very different. It is not rubbish, but there are ways that can try to make the conflicts as= =20 small as possible, but if you want to have an ebuild an hour after a packag= e=20 was released (which I also want) there is not much time to do QA, so things= =20 will break every now and then. If you don't want things to break at all, ev= en=20 in an unstable tree, use debian. Gentoo needs to find a middle road. > I can think of one way to make dealing with unmaintained ebuilds easy > enough. First of all, put in place a mechanism to remove the guesswork > about whether a particular package is maintained or not. Then, create a > pool of developers who will handle new ebuilds for these packages.=20 > Finally, make a site where people can come and tell you when an ebuild is > out of date (or just use Bugzilla). That way, packages that no-one > particularly wants to maintain are driven by 'customer demand' (for lack = of > a better phrase). Final step is to setup some 'tinderbox' machines, where > the unmaintained ebuilds are automatically built. When they finally brea= k, > a bug could be automatically raised on Bugzilla for someone in the pool to > look at it. > Most breakage is not in compilation unfortunately, but in odd combinations = of=20 packages creating broken results. > There's also another way. Encourage more opensource projects to maintain > their own ebuilds. Many of them maintain SPEC files for building RedHat > RPMs. So why not try and distribute the work more widely too? > > What are *your* proposals for addressing this? I'd like to hear them. Well, what I'm doing to address some of these things is the herds project. = It=20 aims to find maintainers for all ebuilds. That way we can identify lost=20 packages, and make sure they are maintained or abandoned. > > > We are trying to address these problems in a way that is > > satisfactory for everyone. > > Are you speaking for yourself, or for TheManagement(tm)? I'm trying to speak for the gentoo project, of which the management is a pa= rt > > > Be assured that these issues are being addressed. This > > requires time though, as restructuring is necessary for it to happen. > > You talk like we should run along and play, and not bother BigPeople(tm) > like yourself. You'll have to excuse me if I don't like that ;-) It's > exactly this sort of *presentation* (I use the work presentation because > you've included nothing of substance in your reply!) that makes people ca= ll > for more openness in the community. Interesting. > I don't consider myself to be a BigPerson(tm), and I don't mind to explain= =20 things, or even to change my opinion because of someone elses arguments. I = do=20 however don't want to bring up false hopes by comming out with proposals th= at=20 need revision and are not ready yet. I can tell you however that we are bus= y=20 finding a solution. I can not tell the solution because there is none yet. The major problems at the moment are responsibilities (who does what), how= =20 will we finalize the management restructuring (as this proposal is part of)= ,=20 how can we rearange things to get better QA, and what to do with "small"=20 ebuilds. Paul =2D-=20 Paul de Vrieze Researcher Mail: pauldv@cs.kun.nl Homepage: http://www.devrieze.net --Boundary-02=_k0+E/DhPz5IVgQy Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/E+0kbKx5DBjWFdsRAkt0AJ9y0QQ9v6mJTVVfIz7WWXzZuTe9KACeKpXM 2Lh6n1rCo/YpfMNMmKjod9U= =ukQI -----END PGP SIGNATURE----- --Boundary-02=_k0+E/DhPz5IVgQy--