1 |
First off, let me just say that this was just an idea I'd cooked up a |
2 |
while back, so I am sure there's lots of holes in it for you guys to rip |
3 |
apart. Anyway, without further ado... |
4 |
|
5 |
The proposal is quite simple insofar as it requires no changes to |
6 |
portage, whatsoever (though there are possibilities to make extensions |
7 |
to portage). It introduces no new KEYWORDS and adds no load on the |
8 |
current ebuild developers, other than those that wish to work on the |
9 |
stable tree. |
10 |
|
11 |
Allow me to explain. |
12 |
|
13 |
First, there is the creation of the "release" tree. This tree is tied |
14 |
to a specific release of Gentoo Linux. The tree is based on the release |
15 |
snapshot used to build the release. The tree consists of the highest |
16 |
version stable ebuild per slot and architecture for each package. This |
17 |
means if there is no stable version of, say, vmware-player, then the |
18 |
entire package is omitted. For things like GTK+, there would be at |
19 |
least 2 versions in the tree, since there are 2 slots and both are |
20 |
stable on at least one architecture. By only limiting the tree in this |
21 |
manner, it can be built entirely by a script and require no manual |
22 |
interactions to repair dependencies, etc. |
23 |
|
24 |
So let's imagine that 2006.0 is rolling around. The 2006.0 snapshot is |
25 |
frozen, and the release-building begins. This snapshot tarball is run |
26 |
through our "stable" script, and a new gentoo-2006.0 CVS module is |
27 |
created. A corresponding rsync module is created for this tree. |
28 |
|
29 |
To facilitate "enterprise" usage, we break up the releases into a |
30 |
"desktop" and "server" set. This means the current |
31 |
"default-linux/$arch/2006.0" profile would be |
32 |
"default-linux/$arch/2006.0/desktop" with a |
33 |
"default-linux/$arch/2006.0/server" profile, also. The stages would be |
34 |
built against the "default-linux/$arch/2006.0" profile, which would have |
35 |
any USE, etc. that are common between desktop and server. During |
36 |
installation, the user can choose to use either the desktop or server |
37 |
profiles, or stay with the more "generic" 2006.0 profile (good for |
38 |
developers, etc. that might need components of both, or want a more |
39 |
minimal default set of USE flags). The desktop and server profiles will |
40 |
have a defined set of default USE flags that will benefit the most |
41 |
people, similar to how the current profiles are designed to be "desktop" |
42 |
profiles, to benefit the most people. |
43 |
|
44 |
The release media has SYNC set to this rsync module. What we would have |
45 |
is SYNC="rsync://rsync.gentoo.org/gentoo-2006.0" in make.conf for this |
46 |
release. Security updates would be applied to gentoo-2006.0, so "emerge |
47 |
--sync" still allows for getting package updates, as we currently do. A |
48 |
user can upgrade to 2006.1 by simply changing the SYNC setting and |
49 |
updating their profile. A simple tool could be created for this, or |
50 |
portage could be extended to allow for it (emerge --distupgrade 2006.1). |
51 |
|
52 |
The current "gentoo-x86" CVS module would be the equivalent to Slackware |
53 |
or FreeBSD's -current tree. Users that wish to participate in Gentoo |
54 |
development, either via actual patches or simply by assisting in testing |
55 |
new packages and filing bug reports, can use this tree with no |
56 |
difference from how they operate now. This would also allow us to get |
57 |
wider testing on the release profiles before the actual release is made. |
58 |
|
59 |
Of course, a team would need to be created to work on the gentoo-$relver |
60 |
trees. However, the trees would already exist with minimal effort on |
61 |
anyone's part, allowing for an easier transition. In the end, this |
62 |
would be only marginally more work for Release Engineering, so I don't |
63 |
see much argument from my project, and minimal to no extra work for any |
64 |
ebuild developers working on gentoo-x86 that do not also volunteer to |
65 |
work on gentoo-$relver. Patches from gentoo-$relver would be |
66 |
"upstreamed" into the gentoo-x86 tree, if they did not originate on |
67 |
gentoo-x86, so the next gentoo-$relver tree would be already fixed. |
68 |
|
69 |
Remember that the release trees would only be security fixes. No other |
70 |
package updates should be happening. This would allow for companies to |
71 |
actually certify their software against "Gentoo 2006.0", for example. |
72 |
|
73 |
Even with no updates going into this tree, as would be the case when it |
74 |
is originally implemented, we would still have a stable, unchanging |
75 |
platform for external parties to test and verify against. They would |
76 |
never be caught unaware with an apache upgrade or a gcc upgrade. They |
77 |
would upgrade to new releases when *they* choose, giving them a stable |
78 |
platform to build their Gentoo systems against. This concept also |
79 |
allows for us to take "baby steps" in getting to a fully-supported set |
80 |
of packages with back-ported security fixes. Because of this, I have |
81 |
specifically omitted any retention or support periods, since I think |
82 |
some kind of consensus would need to be reached on that, and I would |
83 |
prefer that those particular details not cloud this proposal. |
84 |
|
85 |
Speaking hypothetically, it would even be possible to create a separate |
86 |
corporate entity that pays developers to work on gentoo-$relver trees by |
87 |
back-porting patches and providing support to customers. Support and |
88 |
patches could be maintained on any given tree for any length of time |
89 |
decided. Yes, it could be possible for Gentoo to sell support. |
90 |
|
91 |
I'm sure I'm missing a lot and this will be discussed to death, but this |
92 |
is also the kind of thing that we definitely want to do right if we do |
93 |
it, so feel free to punch holes all in this proposal (and I know you |
94 |
will... :P). |
95 |
|
96 |
-- |
97 |
Chris Gianelloni |
98 |
Release Engineering - Strategic Lead |
99 |
x86 Architecture Team |
100 |
Games - Developer |
101 |
Gentoo Linux |