From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28356 invoked by uid 1002); 15 Jul 2003 11:40:22 -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 2474 invoked from network); 15 Jul 2003 11:40:21 -0000 Reply-To: From: "Stuart Herbert" To: "'Paul de Vrieze'" , Date: Tue, 15 Jul 2003 12:39:54 +0100 Keywords: Of Interest, Unread Email Organization: Generic NQS Project Message-ID: <03d901c34ac5$d249a3c0$c200a8c0@Churchill> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <200307151319.13920.pauldv@gentoo.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: RE: [gentoo-dev] Gentoo part II. X-Archives-Salt: 519b9cde-7199-41c2-8e10-be87f74aa8bd X-Archives-Hash: afd33c84cb3bd970d9a7428fe776aaa7 > I hope you realise that your desires are conflicting. more=20 > ebuilds leads to=20 > 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. 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. = 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 break, a bug could = be automatically raised on Bugzilla for someone in the pool to look at it. 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. > We are trying to address these problems in a way that is=20 > satisfactory for everyone. Are you speaking for yourself, or for TheManagement(tm)? > Be assured that these issues are being addressed. This=20 > 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 = call for more openness in the community. Interesting. Best regards, Stu -- -- gentoo-dev@gentoo.org mailing list