From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21106 invoked from network); 3 Jul 2004 06:35:36 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 3 Jul 2004 06:35:36 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1Bge7b-0004ui-Bj for arch-gentoo-dev@lists.gentoo.org; Sat, 03 Jul 2004 06:35:35 +0000 Received: (qmail 32289 invoked by uid 89); 3 Jul 2004 06:35:34 +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 25072 invoked from network); 3 Jul 2004 06:35:34 +0000 From: Dylan Carlson Reply-To: absinthe@gentoo.org To: gentoo-dev@lists.gentoo.org Date: Sat, 3 Jul 2004 02:34:18 -0400 User-Agent: KMail/1.6.2 References: <40E4B84B.1040501@scms.waikato.ac.nz> <200407021706.44649.absinthe@gentoo.org> <1088804249.9271.55.camel@localhost> In-Reply-To: <1088804249.9271.55.camel@localhost> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200407030234.18628.absinthe@gentoo.org> Subject: Re: [gentoo-dev] Policy for retirement of old gentoo 'versions' X-Archives-Salt: 2e08e00d-5d2a-4781-8d6a-b304e0f933d1 X-Archives-Hash: e53659a3dd80d716be706411f9ebbf2f On Friday 02 July 2004 5:37 pm, Chris Gianelloni wrote: > Pinning versions in the profiles sounds pretty cool, but it turns > *every* package maintainer and arch maintainer into a profile > maintainer, which I think is a bad idea. It also bloats the portage > tree, since there would be multiple versions of every ebuild, compared > to the one or two for most packages that we have now. I still think > that the "pinned" tree should be a separate branch. It wouldn't turn everyone into profile maintainers -- it would just ensure that no ebuild gets removed accidentally that is required by a profile, by repoman's QA check. If that ebuild *needs* to be removed for any reason (let's say a vulnerability) then it would be up to the arch herds to update their profile(s) accordingly -- not up to the herd/maintainer of the package. The CVS branching / Gentoo Enterprise idea (to me) sounds overengineered. I haven't done a survey of IT managers to see what their expectations are, but in my 14 years, management, etc -- I know what /my/ basic requirements are. 1/ Conservative defaults 2/ A regular, predictable release schedule 3/ Packages are not updated between releases, except in cases of vulnerabilities or major bugfixes 4/ In the event of #3, basic regression testing before the changes are committed 5/ Supporting documentation & tools geared towards enterprise deployment I would agree that it's more elegant and ideal to have them maintained independently. Yet, it's easier for a commercial entity like, say, RedHat to offer Enterprise on one hand, and then Fedora on the other, as separate branches of development. They've got a consistent revenue stream and a sizeable staff of paid developers & support techs who clock in 40-50 hrs/wk guiding both products. Given the flux nature of volunteer developers I'm not positive we can live up to those same expectations if we attempt to maintain two separate trees. However we can get the job done with repoman, some developer/QA policy tweaks, and pinning packages in profiles. It seems to be a simpler solution, and we don't need to segregate the dev pool to do it. People can contribute to both sides if they know what the rules of engagement are. I'm sure we have intelligent people working on this; this is just my take. Simpler solutions tend to work better for free projects. Cheers, Dylan Carlson [absinthe@gentoo.org] Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F -- gentoo-dev@gentoo.org mailing list