From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 444 invoked from network); 21 Jul 2004 19:59:19 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 21 Jul 2004 19:59:19 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1BnMuI-00018M-AP for arch-gentoo-dev@lists.gentoo.org; Wed, 21 Jul 2004 19:37:47 +0000 Received: (qmail 16661 invoked by uid 89); 21 Jul 2004 19:37:16 +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 7199 invoked from network); 21 Jul 2004 19:37:15 +0000 From: Chris Gianelloni Reply-To: wolf31o2@gentoo.org To: gentoo-dev@lists.gentoo.org In-Reply-To: <200407201643.25486.absinthe@gentoo.org> References: <20040720131405.GW18023@mail.lieber.org> <200407201643.25486.absinthe@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-RLA9f0BNYy7i3M8aMI8c" Organization: Gentoo Linux Message-Id: <1090440033.11369.111.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 21 Jul 2004 16:00:34 -0400 Subject: Re: [gentoo-dev] Revisiting GLEP 19 X-Archives-Salt: 0f106559-2a80-4c36-a0ef-843f37eb0c8a X-Archives-Hash: 365e13c70adcc82c5da2dcc93b1623f7 --=-RLA9f0BNYy7i3M8aMI8c Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-07-20 at 16:43, Dylan Carlson wrote: > 1/ Many Gentoo users want the ability to update packages for fixes only=20 > (and not just for servers) Agreed. > 2/ Maintaining separate trees in CVS is probably asking too much of our=20 > current roster, plus requires adding infrastructure and getting everyone=20 > to mirror the new tree(s) Agreed. > 3/ Users already have a good understanding of what profiles are. This is= =20 > useful. Possibly... The current Gentoo profile system would need to be modified to allow for changes. This might be workable using cascading profiles, though. > 4/ Creating separate CVS trees while also using profiles seems superfluou= s. Agreed. > Therefore I believe another possible solution is to change the way we use= =20 > profiles (both in practice and in QA policy): I'm not sure I like the idea of changing profiles for any reason. As many people agreed when I asked about the creation of the default-x86-2004.2 profile for the switch from xfree to xorg-x11 on x86, a user should expect the same packages be installed by the same profile, no matter where in the release cycle or on what day they do their install. You *will* notice that I say "packages" and not "package versions" in that statement. > Implications: >=20 > 1/ archs will need to have a regular, predictable release schedule,=20 > probably at least every six months. Like our current quarterly release schedule? > 2/ profiles will list specific package versions whenever possible. e.g.: > =3Dsys-libs/glibc-2.3.2 This would make it impossible to upgrade the version. A version should never be pinned in a profile. > 3/ we will need to prepare a list of packages which should not change=20 > unless the user switches profiles. those packages (e.g., toolchain) in=20 > the current, and older profiles do not get updated except for fixes. =20 No package should change. Package versions should only change for major fixes/security updates. I'm not sure I see the point in this one, since the list would be redundant. > 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) 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. > 5/ we will need to have documentation for users who are upgrading from on= e=20 > profile to another (upgrade warnings, instructions and considerations) Agreed, whether it be profile-based or not. > 6/ repoman will need to be enhanced to check the profiles before removing= =20 > any ebuilds from the tree that might be needed. specific versions pinned= =20 > in profiles need to stay until the profile is changed. I agree that changes would need to be made. I just am not sure that a profile is what would bring about such changes. Honestly, the problem that we face is manpower. Plain and simple. In many cases, we don't have enough developers for what we already are doing. No matter what we decide as a technical solution to a stable tree, I just don't see a possible way to solve these problems without adding a massive number of developers. 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. Here is my ideas on how this could be done. Feel free to rip them apart... Some of the ideas here would require some large changes to our Standard Operating Procedure. 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. 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... ...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 *** With my method, a user can change between releases simply by overriding SYNC in make.conf to whatever release they wish, or even to -current.=20 The upgrade would be just like doing a massive "emerge sync && emerge -u world" after not syncing for 6 months. Everything would upgrade smoothly. We would update the user's profile at sync time, too. We would need to include some form of logic to know whether our rsync mirror choice has changed, and take appropriate actions. For example, if I were going from 2005.0 to 2005.1 and running an amd64 with the gcc34 profile, if there is an amd64/2005.1/gcc34 profile, then the switch is simple. If amd64 has adopted gcc 3.4 as the default, then the profile would revert to the default. Is there anything I missed? Discuss amongst yourselves... --=20 Chris Gianelloni Release Engineering QA Manager/Games Developer Gentoo Linux Is your power animal a penguin? --=-RLA9f0BNYy7i3M8aMI8c 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/sthkT4lNIS36YERAgWIAKDBdaED+cdf1RZR1eYSHb1ZLEpkHwCdG8HQ unnYtkjdKhq16PIX2fsJMko= =OGIQ -----END PGP SIGNATURE----- --=-RLA9f0BNYy7i3M8aMI8c--