Matt, Ron,

I agree with you both - to a point.  The current CVS strategy has gotten 
Gentoo this far, but it needs to evolve if Gentoo is to become more friendly 
to large companies.  It is being talked about amongst key Gentoo developers, 
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 
anything to do with Portage.  Right now, I don't see any clear or consistent 
understanding of what 'stable' means, and I don't think that the term is 
actually very helpful.  Does 'stable' mean fit for production use?  Does it 
simply mean 'the ebuild works, and the app doesn't segfault when you fire it 
up'?  It's not helpful.

If Gentoo moves to a multiple-tree strategy, -CURRENT is fair enough I guess, 
as are -RELEASE branches (although the whole idea of a RELEASE needs 
re-considering too I believe).  But what would -STABLE in between actually 
mean?  We need a better word.  Heck, even -UNMASKED would be a better start - 
at least it's more accurate, and something that we could reach a clear 
definition on.

I believe that ebuilds *should* have a guaranteed minimum life expectency in 
the Portage tree; I also believe that developers *should* announce the 
removal of an ebuild before it is removed, to give time for any necessary 
debate or local archiving into /usr/local/portage.  Right now, a) it doesn't 
happen, and b) there's nowhere suitable to make the announcement anyway.  You 
can find out more about my opinion on managing individual ebuilds by reading 
a draft document on dev.gentoo.org/~stuart/sponsorship/.  You'll need a PDF 
reader to read it.

Getting back to managing the larger Portage tree ... I don't agree that 
providing support for 'tagged branches' is just as simple as making the 
tagged branches available for x period of time.  A 'tagged branch' wouldn't 
be suitable for any large software provider to certify against - because it's 
an incomplete target.  A tagged branch is just a bunch of ebuilds.  It 
doesn't include the compiler you used, the CFLAGS you used, or the 
architecture you're running on.  And the moment a branch is tagged, it 
becomes a liability.

Let's look at a traditional SCM (software change management) problem for a 
moment.  What happens to the 'tagged branch' when security problems are 
found?  What about when important bug fixes are needed?  Would we backport 
those ebuilds into the tagged branches?  Where would that effort come from?  
Who would do that work?

Look at the alternative - withdraw a particular tagged branch, and tell users 
to upgrade to a different tagged branch.  Unfortunately, you're going to have 
an unpredictable amount of change between those branches.  The effort of 
moving could be high, and would be difficult to plan for in advance.  We'd 
end up like - shall we say - certain older distributions, where from time to 
time wiping the box is less hassle than performing the upgrade.

What does a certification program involve?  Any QA practice that is more than 
cosmetic would include SCM, and the SCM team would require that the exact 
versions of libraries and supporting utilities are identified and documented.  
Which is exactly how ebuilds work in practice.  You'd have to throw in 
environmental factors - hardware, file systems & disk layouts, etc etc - but 
the ebuild is at the heart of it, and not the wider distribution.  If all the 
technical factors are satisfied, then the QA practice would approve 
certification.  Although a tag is a convenient way of saying that all these 
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 
practice.  In reality, certifications are a political tool as much as a 
technical one - and there Gentoo will face new challenges for sure.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Beta packages for download            http://dev.gentoo.org/~stuart/packages/
Come and meet me in March 2004                 http://www.phparch.com/cruise/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--