On Wed, 2004-07-21 at 17:57, Michael Marineau wrote:
> I also like the seperate trees.  And splitting out the base system into a
> tarball and putting only updates in the rsync tree is certainly doable.
> However, dividing out between a release tarball and synced updates begins to
> distroy the elegence that only switching a portage tree has.  I don't really
> see why using rsync will overburden the mirrors any more than they are now.
> Afterall, currently everyone has to rsync.  If it is so important to use
> tarballs maybe it would work to just provide update snapshots that can be
> downloaded and inserted into the existing tree. Snapshots could be done by
> either grabbing the whole tree or just include new or updated ebuilds.  Basicly
> it would be encouraging enerprise users to use emerge-webrsync instead of
> emerge sync.  Personally though, I don't think avoiding rsync would really help
> that much.

I'm not sure why rsync would be too bad myself.  I merely mentioned
another option.  As I said originally, I'm totally open to discussion. 
I definitely like the simplicity in my original comment of switching
portage trees.

> Who maintains the old trees is a pretty big issue.  Is this more serious than
> just determining how many releases to support and will actually limit how
> 'enterprise' like enterprise gentoo will be?  There have been a far range of
> needs that could be addressed.  Can gentoo do it all or just rehash fancy ways
> of doing `glsa-check`?

I totally agree.  I also think that being a community-based distribution
that doesn't have the resources that many other distributions can
afford, perhaps we should just start implementing what we can.  Would it
really be so bad to just do the -release trees, even if we didn't
provide updates for everything to begin with?  While this might not be
popular with everyone, I am sure there are a number of people who would
use the tree, and just like the -current portage tree that has gained
developers and other things over time, it would *evolve* into an
enterprise style product, rather than us never releasing anything of the
sort due to trying to solve all the problems at once.  Once again I ask,
is it better to try and fail, than to not try at all?  I mean, if we
tried to do this and weren't able to accomplish it, we would be able to
show people exactly why we were unable to do so, rather than give them
all these reasons of why we *think* we can't do it.

After all, in the open source world, you never know what can happen. 
IBM may step up and decide to throw some developers at helping us keep
the -release trees up to date... or Novell... or anybody.  You just
don't know and you can't say that it won't happen because nobody can
tell the future.  Perhaps we'll simply get enough ebuild submissions and
patches from the people using the -release trees that we'll be able to
sustain.  After all, the biggest problem everyone has with the -release
trees is "who's going to maintain it", but it is infinitely easier to
test a patch that someone has provided to solve a problem than it is to
locate the problem, figure out how to fix it, write a patch, and test a
patch.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?