| 1 |
On Wed, 2004-07-21 at 17:57, Michael Marineau wrote: |
| 2 |
> I also like the seperate trees. And splitting out the base system into a |
| 3 |
> tarball and putting only updates in the rsync tree is certainly doable. |
| 4 |
> However, dividing out between a release tarball and synced updates begins to |
| 5 |
> distroy the elegence that only switching a portage tree has. I don't really |
| 6 |
> see why using rsync will overburden the mirrors any more than they are now. |
| 7 |
> Afterall, currently everyone has to rsync. If it is so important to use |
| 8 |
> tarballs maybe it would work to just provide update snapshots that can be |
| 9 |
> downloaded and inserted into the existing tree. Snapshots could be done by |
| 10 |
> either grabbing the whole tree or just include new or updated ebuilds. Basicly |
| 11 |
> it would be encouraging enerprise users to use emerge-webrsync instead of |
| 12 |
> emerge sync. Personally though, I don't think avoiding rsync would really help |
| 13 |
> that much. |
| 14 |
|
| 15 |
I'm not sure why rsync would be too bad myself. I merely mentioned |
| 16 |
another option. As I said originally, I'm totally open to discussion. |
| 17 |
I definitely like the simplicity in my original comment of switching |
| 18 |
portage trees. |
| 19 |
|
| 20 |
> Who maintains the old trees is a pretty big issue. Is this more serious than |
| 21 |
> just determining how many releases to support and will actually limit how |
| 22 |
> 'enterprise' like enterprise gentoo will be? There have been a far range of |
| 23 |
> needs that could be addressed. Can gentoo do it all or just rehash fancy ways |
| 24 |
> of doing `glsa-check`? |
| 25 |
|
| 26 |
I totally agree. I also think that being a community-based distribution |
| 27 |
that doesn't have the resources that many other distributions can |
| 28 |
afford, perhaps we should just start implementing what we can. Would it |
| 29 |
really be so bad to just do the -release trees, even if we didn't |
| 30 |
provide updates for everything to begin with? While this might not be |
| 31 |
popular with everyone, I am sure there are a number of people who would |
| 32 |
use the tree, and just like the -current portage tree that has gained |
| 33 |
developers and other things over time, it would *evolve* into an |
| 34 |
enterprise style product, rather than us never releasing anything of the |
| 35 |
sort due to trying to solve all the problems at once. Once again I ask, |
| 36 |
is it better to try and fail, than to not try at all? I mean, if we |
| 37 |
tried to do this and weren't able to accomplish it, we would be able to |
| 38 |
show people exactly why we were unable to do so, rather than give them |
| 39 |
all these reasons of why we *think* we can't do it. |
| 40 |
|
| 41 |
After all, in the open source world, you never know what can happen. |
| 42 |
IBM may step up and decide to throw some developers at helping us keep |
| 43 |
the -release trees up to date... or Novell... or anybody. You just |
| 44 |
don't know and you can't say that it won't happen because nobody can |
| 45 |
tell the future. Perhaps we'll simply get enough ebuild submissions and |
| 46 |
patches from the people using the -release trees that we'll be able to |
| 47 |
sustain. After all, the biggest problem everyone has with the -release |
| 48 |
trees is "who's going to maintain it", but it is infinitely easier to |
| 49 |
test a patch that someone has provided to solve a problem than it is to |
| 50 |
locate the problem, figure out how to fix it, write a patch, and test a |
| 51 |
patch. |
| 52 |
|
| 53 |
-- |
| 54 |
Chris Gianelloni |
| 55 |
Release Engineering QA Manager/Games Developer |
| 56 |
Gentoo Linux |
| 57 |
|
| 58 |
Is your power animal a penguin? |
Archives