From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8390 invoked from network); 22 Jul 2004 12:18:40 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 22 Jul 2004 12:18:40 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1BncX2-0002rj-4c for arch-gentoo-dev@lists.gentoo.org; Thu, 22 Jul 2004 12:18:40 +0000 Received: (qmail 1758 invoked by uid 89); 22 Jul 2004 12:18:35 +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 21796 invoked from network); 22 Jul 2004 12:18:34 +0000 From: Chris Gianelloni Reply-To: wolf31o2@gentoo.org To: gentoo-dev@lists.gentoo.org In-Reply-To: <40FEE6B0.4020500@engr.orst.edu> References: <20040720131405.GW18023@mail.lieber.org> <200407201643.25486.absinthe@gentoo.org> <1090440033.11369.111.camel@localhost> <1090444335.372.18.camel@montreal> <40FEE6B0.4020500@engr.orst.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-c9xiro/Y+wFLo0o/R0xa" Organization: Gentoo Linux Message-Id: <1090499090.22438.25.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 22 Jul 2004 08:24:50 -0400 Subject: Re: [gentoo-dev] Revisiting GLEP 19 X-Archives-Salt: 835f240b-844d-48c8-8473-0731fe64e827 X-Archives-Hash: 89a4782be5bea0852688984f62cd0a66 --=-c9xiro/Y+wFLo0o/R0xa Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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 rea= lly > see why using rsync will overburden the mirrors any more than they are no= w. > 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 b= y > either grabbing the whole tree or just include new or updated ebuilds. B= asicly > it would be encouraging enerprise users to use emerge-webrsync instead of > emerge sync. Personally though, I don't think avoiding rsync would reall= y 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.=20 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.=20 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. --=20 Chris Gianelloni Release Engineering QA Manager/Games Developer Gentoo Linux Is your power animal a penguin? --=-c9xiro/Y+wFLo0o/R0xa Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBA/7IRkT4lNIS36YERAnguAJ94NCQmLEhdGM+3jm96sWgRsQppwwCdHe0f 1U46Q06ZxZxT3icxqUz85us= =UqGq -----END PGP SIGNATURE----- --=-c9xiro/Y+wFLo0o/R0xa--