A few points... On Tue, 2004-02-03 at 15:55, Kurt Lieber wrote: > There are two main issues that I want to focus on as possible alternatives > for implementing this GLEP. > > 1) Tarballs for main tree, rsync for security/bugfixes. > > Several folks have indicated that they feel quarterly updates are too > frequent. I personally feel that semi-annual or annual updates are too > infrequent and put us at risk of contracting Debian Stable-itis. > > One alternative I thought of (inspired by a suggestion from Spider) was to > create and distribute each quarterly release as a tbz2 and then have a > single rsync tree that only contains security updates and bugfixes. These > off-cycle changes would, as Spider suggested, be made available via an > overlay to avoid corrupting the original tree.
I think this tarball idea is very good.. Debian Stable has actually many good things that we should emulate, one of them being stability (ie it doesnt change often) and the other being stability (it has very good QA)... Its much easier to keep more tarballs on the mirrors without overloading them too.. > The main disadvantages I can see with this are: > > * Requires portage support to work. (or users will have to do a lot > of manual syncing) The original GLEP requires no changes to portage. Why new portage support? Upgrading would be "rm -rf /usr/portage-stable/*; tar xzvf -C /usr/portage-stable/ tarball.tbz2 or something like that.. Having it as non-rsync is actually a feature... I dont want to update my stable tree by mistake! > * Could cause problems if some of the security updates have newer deps that > are otherwise not included in the stable tree. Security updates should be back-ported if the deps can't be met... I dont see how we can get around that... and call it stable... But that's not an infrastructure matter, I agree.. But as soon as anything called like stable is implemented we are going to have to discuss QA stuff.. I can volunteer to help maintain a very stable tree... -- Olivier Cr�te [EMAIL PROTECTED] Gentoo Developer
signature.asc
Description: This is a digitally signed message part
