Re: [gentoo-dev] Policy for retirement of old gentoo 'versions'

[Dylan Carlson]

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@g.o]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@g.o mailing list