From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26550 invoked by uid 1002); 18 Aug 2003 14:16:56 -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 30327 invoked from network); 18 Aug 2003 14:16:56 -0000 From: Stuart Herbert Reply-To: stuart@gentoo.org To: gentoo-dev@gentoo.org Date: Mon, 18 Aug 2003 15:14:49 +0100 User-Agent: KMail/1.5.3 References: <3F3FFCFF.2080804@sentuny.com.au> <3F400F68.3080806@sentuny.com.au> <20030817172207.54a6de08.xwred1@xwredwing.net> In-Reply-To: <20030817172207.54a6de08.xwred1@xwredwing.net> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_Z9NQ/ZUwfI8yvJl"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200308181514.49195.stuart@gentoo.org> Subject: Re: [gentoo-dev] Large scale deployments - and portage X-Archives-Salt: a0d62195-1003-49cd-b1d3-3cad9ebae3ed X-Archives-Hash: 74eb3b395be28af01c7a1d6721445f13 --Boundary-02=_Z9NQ/ZUwfI8yvJl Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline Matt, Ron, I agree with you both - to a point. The current CVS strategy has gotten=20 Gentoo this far, but it needs to evolve if Gentoo is to become more friendl= y=20 to large companies. It is being talked about amongst key Gentoo developers= ,=20 but at the moment I don't know the current status, or any timescales. One thing I'd like to see is the eradication of the word 'stable' from=20 anything to do with Portage. Right now, I don't see any clear or consisten= t=20 understanding of what 'stable' means, and I don't think that the term is=20 actually very helpful. Does 'stable' mean fit for production use? Does it= =20 simply mean 'the ebuild works, and the app doesn't segfault when you fire i= t=20 up'? It's not helpful. If Gentoo moves to a multiple-tree strategy, -CURRENT is fair enough I gues= s,=20 as are -RELEASE branches (although the whole idea of a RELEASE needs=20 re-considering too I believe). But what would -STABLE in between actually= =20 mean? We need a better word. Heck, even -UNMASKED would be a better start= -=20 at least it's more accurate, and something that we could reach a clear=20 definition on. I believe that ebuilds *should* have a guaranteed minimum life expectency i= n=20 the Portage tree; I also believe that developers *should* announce the=20 removal of an ebuild before it is removed, to give time for any necessary=20 debate or local archiving into /usr/local/portage. Right now, a) it doesn'= t=20 happen, and b) there's nowhere suitable to make the announcement anyway. Y= ou=20 can find out more about my opinion on managing individual ebuilds by readin= g=20 a draft document on dev.gentoo.org/~stuart/sponsorship/. You'll need a PDF= =20 reader to read it. Getting back to managing the larger Portage tree ... I don't agree that=20 providing support for 'tagged branches' is just as simple as making the=20 tagged branches available for x period of time. A 'tagged branch' wouldn't= =20 be suitable for any large software provider to certify against - because it= 's=20 an incomplete target. A tagged branch is just a bunch of ebuilds. It=20 doesn't include the compiler you used, the CFLAGS you used, or the=20 architecture you're running on. And the moment a branch is tagged, it=20 becomes a liability. Let's look at a traditional SCM (software change management) problem for a= =20 moment. What happens to the 'tagged branch' when security problems are=20 found? What about when important bug fixes are needed? Would we backport= =20 those ebuilds into the tagged branches? Where would that effort come from?= =20 Who would do that work? Look at the alternative - withdraw a particular tagged branch, and tell use= rs=20 to upgrade to a different tagged branch. Unfortunately, you're going to ha= ve=20 an unpredictable amount of change between those branches. The effort of=20 moving could be high, and would be difficult to plan for in advance. We'd= =20 end up like - shall we say - certain older distributions, where from time t= o=20 time wiping the box is less hassle than performing the upgrade. What does a certification program involve? Any QA practice that is more th= an=20 cosmetic would include SCM, and the SCM team would require that the exact=20 versions of libraries and supporting utilities are identified and documente= d. =20 Which is exactly how ebuilds work in practice. You'd have to throw in=20 environmental factors - hardware, file systems & disk layouts, etc etc - bu= t=20 the ebuild is at the heart of it, and not the wider distribution. If all t= he=20 technical factors are satisfied, then the QA practice would approve=20 certification. Although a tag is a convenient way of saying that all these= =20 factors *should* be present, Gentoo's ebuilds provide a viable alternative. I really don't see how the Gentoo approach is incompatible with that QA=20 practice. In reality, certifications are a political tool as much as a=20 technical one - and there Gentoo will face new challenges for sure. Best regards, Stu =2D-=20 Stuart Herbert stuart@gentoo.o= rg Gentoo Developer http://www.gentoo.or= g/ Beta packages for download http://dev.gentoo.org/~stuart/package= s/ Come and meet me in March 2004 http://www.phparch.com/cruis= e/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint =3D 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C =2D- --Boundary-02=_Z9NQ/ZUwfI8yvJl Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/QN9ZDC+AuvmvxXwRAkokAJ9E7ajo+99qnps5Cxuut+d8KVWGkQCbBCr4 1fw73iAtRpIgfoZUNlQgleM= =yYZU -----END PGP SIGNATURE----- --Boundary-02=_Z9NQ/ZUwfI8yvJl--