From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21514 invoked from network); 21 Jul 2004 21:12:21 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 21 Jul 2004 21:12:21 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1BnONv-0005p7-8r for arch-gentoo-dev@lists.gentoo.org; Wed, 21 Jul 2004 21:12:19 +0000 Received: (qmail 10307 invoked by uid 89); 21 Jul 2004 21:12:18 +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 23873 invoked from network); 21 Jul 2004 21:12:18 +0000 From: Olivier Crete To: gentoo-dev@lists.gentoo.org In-Reply-To: <1090440033.11369.111.camel@localhost> References: <20040720131405.GW18023@mail.lieber.org> <200407201643.25486.absinthe@gentoo.org> <1090440033.11369.111.camel@localhost> Content-Type: text/plain; charset=UTF-8 Organization: Gentoo Date: Wed, 21 Jul 2004 17:12:14 -0400 Message-Id: <1090444335.372.18.camel@montreal> Mime-Version: 1.0 X-Mailer: Evolution 1.5.90 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -4.2 (----) X-Spam-Report: Spam detection software, running on the system "mx.max-t.internal", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or block similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hey, On Wed, 2004-07-21 at 16:00 -0400, Chris Gianelloni wrote: > > 4/ we will need to have a policy about how long we'll support a profile, > > and a procedure for end-of-lifing profiles. (probably don't want to > > support a single profile for more than 2 years) > > I think we had decided that a good number was 4 releases. Now, the > length of time for that would be determined by the release schedule, > naturally. The biggest problem will be our lack of manpower to back > port fixes. I really don't see us overcoming this problem any time > soon. [...] Content analysis details: (-4.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.7 AWL AWL: Auto-whitelist adjustment Subject: Re: [gentoo-dev] Revisiting GLEP 19 X-Archives-Salt: fab6e853-0ee1-458d-a7b8-e6edce5ac9d4 X-Archives-Hash: 7cfba549955dacab490bc95f30f029f2 Hey, On Wed, 2004-07-21 at 16:00 -0400, Chris Gianelloni wrote: > > 4/ we will need to have a policy about how long we'll support a profile= ,=20 > > and a procedure for end-of-lifing profiles. (probably don't want to=20 > > support a single profile for more than 2 years) >=20 > I think we had decided that a good number was 4 releases. Now, the > length of time for that would be determined by the release schedule, > naturally. The biggest problem will be our lack of manpower to back > port fixes. I really don't see us overcoming this problem any time > soon. Four releases a year is way to many.. after two years its 8 releases to support.. This vastly exceeds our current man-power.. Debian with its over 1000 devs only maintains one. One a year seems like a better number to me (maybe two a year). In the multiple profile scenario.. that would create possibly hundreds of ebuilds to be kept in the tree for a single package (one per release per arch and then a few unstable... thinking of a package like glibc)..=20 > I can see how profiles could be used to accomplish this sort of thing, > but pinning of versions would not be the way to go about it. I agree > For simplicity, I'm going to name everything, but none of this is set in > stone. For one, the "gentoo-x86" CVS module would be come > "gentoo-current", as it reflects the actual usage and state of the > tree. The profiles in the current tree would have their versions > removed, as this is a fluid target. This matches our current tree the > best, and allows for us to make dynamic changes to the profiles between > releases. For example, default-x86-2005.0 (or > default-linux/x86/2005.0), would become default-linux/x86/current. Each > release tree would be identified as such. I'm going to work with > cascading profiles, to make my life easier. At release time, a branch > is made for the release. We would take the stable ebuilds/packages from > gentoo-current and drop it into gentoo-2005.0-release and a new profile > default-linux/x86/2005.0 would be created. This profile would never > change. If there were multiple sets of stages created, such as the > amd64 release for 2004.2, which will have both gcc 3.3 and gcc 3.4 > stages, a sub-profile would be created, > default-linux/amd64/2005.0/gcc34. >=20 > At this point, the -release tree is turned over to -releng and the arch > leads/maintainers for preparation for the impending release. If changes > are needed that only affect the LiveCD/GRP, they go into the tree > directly. If changes are needed that affect the package as a whole, the > package maintainer is contacted, and the package is fixed in both the > -current and -release trees. At some point, the tree is frozen and a > snapshot is made. This becomes the official snapshot for that release.=20 > A new rsync mirror set is created for the tree, and the make.globals > SYNC is set to that new rsync mirror, > rsync://rsync.gentoo.org/gentoo-2005.0-release/. The stages/LiveCD/GRP > is built for the release, and everything is golden. The things that are > marked as "stable" are never changed via rsync in this tree, as they are > the unchanging base. The release is made, the planets align, and there > is peace for a thousand generations... I like the idea of a separate tree.. But if it really rarely changes, rsync is just overkill and will overburden our mirrors.. Lets just make it a tarball and put the enhancements in a rsync'ed overlay. Rsync is for stuff that changes... > ...until disaster strikes and a package has a security vulnerability.=20 > At this point, the package is patched, a GLSA is released, and the new > ebuild goes into the tree as ~arch. You will notice that I have left > out the whole "who does the updates" part of this and there is a good > reason for it. I haven't got a clue. This would need to be decided by > interest. After all, many people are not going to be very excited about > applying patches to old versions of software, and that's ok. > *** This is the weakness in not only my plan, but ANY "Enterprise > Gentoo" plan *** This overlays should probably each have their own cvs module (or all be directories under the same module, I dont really care... Where all package maintainers would have access.. And then we can mark them stable using the same kind of procedures we currently use for GLSAs... Also, the problem with maintaining older versions is that we need to have at least one machine available for each version where the concerned devs can test security updates.. Ok, maybe at least one per architectures using chroots... but its still a lot of infrastructure.. That's why reducing the number of stable releases to maybe even just one a year might be a good idea. --=20 Olivier Cr=C3=AAte tester@gentoo.org Gentoo Developer -- gentoo-dev@gentoo.org mailing list