First off, let me just say that this was just an idea I'd cooked up a
while back, so I am sure there's lots of holes in it for you guys to rip
apart. Anyway, without further ado...
The proposal is quite simple insofar as it requires no changes to
portage, whatsoever (though there are possibilities to make extensions
to portage). It introduces no new KEYWORDS and adds no load on the
current ebuild developers, other than those that wish to work on the
stable tree.
Allow me to explain.
First, there is the creation of the "release" tree. This tree is tied
to a specific release of Gentoo Linux. The tree is based on the release
snapshot used to build the release. The tree consists of the highest
version stable ebuild per slot and architecture for each package. This
means if there is no stable version of, say, vmware-player, then the
entire package is omitted. For things like GTK+, there would be at
least 2 versions in the tree, since there are 2 slots and both are
stable on at least one architecture. By only limiting the tree in this
manner, it can be built entirely by a script and require no manual
interactions to repair dependencies, etc.
So let's imagine that 2006.0 is rolling around. The 2006.0 snapshot is
frozen, and the release-building begins. This snapshot tarball is run
through our "stable" script, and a new gentoo-2006.0 CVS module is
created. A corresponding rsync module is created for this tree.
To facilitate "enterprise" usage, we break up the releases into a
"desktop" and "server" set. This means the current
"default-linux/$arch/2006.0" profile would be
"default-linux/$arch/2006.0/desktop" with a
"default-linux/$arch/2006.0/server" profile, also. The stages would be
built against the "default-linux/$arch/2006.0" profile, which would have
any USE, etc. that are common between desktop and server. During
installation, the user can choose to use either the desktop or server
profiles, or stay with the more "generic" 2006.0 profile (good for
developers, etc. that might need components of both, or want a more
minimal default set of USE flags). The desktop and server profiles will
have a defined set of default USE flags that will benefit the most
people, similar to how the current profiles are designed to be "desktop"
profiles, to benefit the most people.
The release media has SYNC set to this rsync module. What we would have
is SYNC="rsync://rsync.gentoo.org/gentoo-2006.0" in make.conf for this
release. Security updates would be applied to gentoo-2006.0, so "emerge
--sync" still allows for getting package updates, as we currently do. A
user can upgrade to 2006.1 by simply changing the SYNC setting and
updating their profile. A simple tool could be created for this, or
portage could be extended to allow for it (emerge --distupgrade 2006.1).
The current "gentoo-x86" CVS module would be the equivalent to Slackware
or FreeBSD's -current tree. Users that wish to participate in Gentoo
development, either via actual patches or simply by assisting in testing
new packages and filing bug reports, can use this tree with no
difference from how they operate now. This would also allow us to get
wider testing on the release profiles before the actual release is made.
Of course, a team would need to be created to work on the gentoo-$relver
trees. However, the trees would already exist with minimal effort on
anyone's part, allowing for an easier transition. In the end, this
would be only marginally more work for Release Engineering, so I don't
see much argument from my project, and minimal to no extra work for any
ebuild developers working on gentoo-x86 that do not also volunteer to
work on gentoo-$relver. Patches from gentoo-$relver would be
"upstreamed" into the gentoo-x86 tree, if they did not originate on
gentoo-x86, so the next gentoo-$relver tree would be already fixed.
Remember that the release trees would only be security fixes. No other
package updates should be happening. This would allow for companies to
actually certify their software against "Gentoo 2006.0", for example.
Even with no updates going into this tree, as would be the case when it
is originally implemented, we would still have a stable, unchanging
platform for external parties to test and verify against. They would
never be caught unaware with an apache upgrade or a gcc upgrade. They
would upgrade to new releases when *they* choose, giving them a stable
platform to build their Gentoo systems against. This concept also
allows for us to take "baby steps" in getting to a fully-supported set
of packages with back-ported security fixes. Because of this, I have
specifically omitted any retention or support periods, since I think
some kind of consensus would need to be reached on that, and I would
prefer that those particular details not cloud this proposal.
Speaking hypothetically, it would even be possible to create a separate
corporate entity that pays developers to work on gentoo-$relver trees by
back-porting patches and providing support to customers. Support and
patches could be maintained on any given tree for any length of time
decided. Yes, it could be possible for Gentoo to sell support.
I'm sure I'm missing a lot and this will be discussed to death, but this
is also the kind of thing that we definitely want to do right if we do
it, so feel free to punch holes all in this proposal (and I know you
will... :P).
--
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux
while back, so I am sure there's lots of holes in it for you guys to rip
apart. Anyway, without further ado...
The proposal is quite simple insofar as it requires no changes to
portage, whatsoever (though there are possibilities to make extensions
to portage). It introduces no new KEYWORDS and adds no load on the
current ebuild developers, other than those that wish to work on the
stable tree.
Allow me to explain.
First, there is the creation of the "release" tree. This tree is tied
to a specific release of Gentoo Linux. The tree is based on the release
snapshot used to build the release. The tree consists of the highest
version stable ebuild per slot and architecture for each package. This
means if there is no stable version of, say, vmware-player, then the
entire package is omitted. For things like GTK+, there would be at
least 2 versions in the tree, since there are 2 slots and both are
stable on at least one architecture. By only limiting the tree in this
manner, it can be built entirely by a script and require no manual
interactions to repair dependencies, etc.
So let's imagine that 2006.0 is rolling around. The 2006.0 snapshot is
frozen, and the release-building begins. This snapshot tarball is run
through our "stable" script, and a new gentoo-2006.0 CVS module is
created. A corresponding rsync module is created for this tree.
To facilitate "enterprise" usage, we break up the releases into a
"desktop" and "server" set. This means the current
"default-linux/$arch/2006.0" profile would be
"default-linux/$arch/2006.0/desktop" with a
"default-linux/$arch/2006.0/server" profile, also. The stages would be
built against the "default-linux/$arch/2006.0" profile, which would have
any USE, etc. that are common between desktop and server. During
installation, the user can choose to use either the desktop or server
profiles, or stay with the more "generic" 2006.0 profile (good for
developers, etc. that might need components of both, or want a more
minimal default set of USE flags). The desktop and server profiles will
have a defined set of default USE flags that will benefit the most
people, similar to how the current profiles are designed to be "desktop"
profiles, to benefit the most people.
The release media has SYNC set to this rsync module. What we would have
is SYNC="rsync://rsync.gentoo.org/gentoo-2006.0" in make.conf for this
release. Security updates would be applied to gentoo-2006.0, so "emerge
--sync" still allows for getting package updates, as we currently do. A
user can upgrade to 2006.1 by simply changing the SYNC setting and
updating their profile. A simple tool could be created for this, or
portage could be extended to allow for it (emerge --distupgrade 2006.1).
The current "gentoo-x86" CVS module would be the equivalent to Slackware
or FreeBSD's -current tree. Users that wish to participate in Gentoo
development, either via actual patches or simply by assisting in testing
new packages and filing bug reports, can use this tree with no
difference from how they operate now. This would also allow us to get
wider testing on the release profiles before the actual release is made.
Of course, a team would need to be created to work on the gentoo-$relver
trees. However, the trees would already exist with minimal effort on
anyone's part, allowing for an easier transition. In the end, this
would be only marginally more work for Release Engineering, so I don't
see much argument from my project, and minimal to no extra work for any
ebuild developers working on gentoo-x86 that do not also volunteer to
work on gentoo-$relver. Patches from gentoo-$relver would be
"upstreamed" into the gentoo-x86 tree, if they did not originate on
gentoo-x86, so the next gentoo-$relver tree would be already fixed.
Remember that the release trees would only be security fixes. No other
package updates should be happening. This would allow for companies to
actually certify their software against "Gentoo 2006.0", for example.
Even with no updates going into this tree, as would be the case when it
is originally implemented, we would still have a stable, unchanging
platform for external parties to test and verify against. They would
never be caught unaware with an apache upgrade or a gcc upgrade. They
would upgrade to new releases when *they* choose, giving them a stable
platform to build their Gentoo systems against. This concept also
allows for us to take "baby steps" in getting to a fully-supported set
of packages with back-ported security fixes. Because of this, I have
specifically omitted any retention or support periods, since I think
some kind of consensus would need to be reached on that, and I would
prefer that those particular details not cloud this proposal.
Speaking hypothetically, it would even be possible to create a separate
corporate entity that pays developers to work on gentoo-$relver trees by
back-porting patches and providing support to customers. Support and
patches could be maintained on any given tree for any length of time
decided. Yes, it could be possible for Gentoo to sell support.
I'm sure I'm missing a lot and this will be discussed to death, but this
is also the kind of thing that we definitely want to do right if we do
it, so feel free to punch holes all in this proposal (and I know you
will... :P).
--
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux
Attached Files:
-
signature.asc (0.18 KB)