1 |
On Tue, 2004-07-20 at 16:43, Dylan Carlson wrote: |
2 |
> 1/ Many Gentoo users want the ability to update packages for fixes only |
3 |
> (and not just for servers) |
4 |
|
5 |
Agreed. |
6 |
|
7 |
> 2/ Maintaining separate trees in CVS is probably asking too much of our |
8 |
> current roster, plus requires adding infrastructure and getting everyone |
9 |
> to mirror the new tree(s) |
10 |
|
11 |
Agreed. |
12 |
|
13 |
> 3/ Users already have a good understanding of what profiles are. This is |
14 |
> useful. |
15 |
|
16 |
Possibly... The current Gentoo profile system would need to be modified |
17 |
to allow for changes. This might be workable using cascading profiles, |
18 |
though. |
19 |
|
20 |
> 4/ Creating separate CVS trees while also using profiles seems superfluous. |
21 |
|
22 |
Agreed. |
23 |
|
24 |
> Therefore I believe another possible solution is to change the way we use |
25 |
> profiles (both in practice and in QA policy): |
26 |
|
27 |
I'm not sure I like the idea of changing profiles for any reason. As |
28 |
many people agreed when I asked about the creation of the |
29 |
default-x86-2004.2 profile for the switch from xfree to xorg-x11 on x86, |
30 |
a user should expect the same packages be installed by the same profile, |
31 |
no matter where in the release cycle or on what day they do their |
32 |
install. You *will* notice that I say "packages" and not "package |
33 |
versions" in that statement. |
34 |
|
35 |
> Implications: |
36 |
> |
37 |
> 1/ archs will need to have a regular, predictable release schedule, |
38 |
> probably at least every six months. |
39 |
|
40 |
Like our current quarterly release schedule? |
41 |
|
42 |
> 2/ profiles will list specific package versions whenever possible. e.g.: |
43 |
> =sys-libs/glibc-2.3.2 |
44 |
|
45 |
This would make it impossible to upgrade the version. A version should |
46 |
never be pinned in a profile. |
47 |
|
48 |
> 3/ we will need to prepare a list of packages which should not change |
49 |
> unless the user switches profiles. those packages (e.g., toolchain) in |
50 |
> the current, and older profiles do not get updated except for fixes. |
51 |
|
52 |
No package should change. Package versions should only change for major |
53 |
fixes/security updates. I'm not sure I see the point in this one, since |
54 |
the list would be redundant. |
55 |
|
56 |
> 4/ we will need to have a policy about how long we'll support a profile, |
57 |
> and a procedure for end-of-lifing profiles. (probably don't want to |
58 |
> support a single profile for more than 2 years) |
59 |
|
60 |
I think we had decided that a good number was 4 releases. Now, the |
61 |
length of time for that would be determined by the release schedule, |
62 |
naturally. The biggest problem will be our lack of manpower to back |
63 |
port fixes. I really don't see us overcoming this problem any time |
64 |
soon. |
65 |
|
66 |
> 5/ we will need to have documentation for users who are upgrading from one |
67 |
> profile to another (upgrade warnings, instructions and considerations) |
68 |
|
69 |
Agreed, whether it be profile-based or not. |
70 |
|
71 |
> 6/ repoman will need to be enhanced to check the profiles before removing |
72 |
> any ebuilds from the tree that might be needed. specific versions pinned |
73 |
> in profiles need to stay until the profile is changed. |
74 |
|
75 |
I agree that changes would need to be made. I just am not sure that a |
76 |
profile is what would bring about such changes. |
77 |
|
78 |
Honestly, the problem that we face is manpower. Plain and simple. In |
79 |
many cases, we don't have enough developers for what we already are |
80 |
doing. No matter what we decide as a technical solution to a stable |
81 |
tree, I just don't see a possible way to solve these problems without |
82 |
adding a massive number of developers. |
83 |
|
84 |
I can see how profiles could be used to accomplish this sort of thing, |
85 |
but pinning of versions would not be the way to go about it. |
86 |
|
87 |
Here is my ideas on how this could be done. Feel free to rip them |
88 |
apart... Some of the ideas here would require some large changes to our |
89 |
Standard Operating Procedure. |
90 |
|
91 |
For simplicity, I'm going to name everything, but none of this is set in |
92 |
stone. For one, the "gentoo-x86" CVS module would be come |
93 |
"gentoo-current", as it reflects the actual usage and state of the |
94 |
tree. The profiles in the current tree would have their versions |
95 |
removed, as this is a fluid target. This matches our current tree the |
96 |
best, and allows for us to make dynamic changes to the profiles between |
97 |
releases. For example, default-x86-2005.0 (or |
98 |
default-linux/x86/2005.0), would become default-linux/x86/current. Each |
99 |
release tree would be identified as such. I'm going to work with |
100 |
cascading profiles, to make my life easier. At release time, a branch |
101 |
is made for the release. We would take the stable ebuilds/packages from |
102 |
gentoo-current and drop it into gentoo-2005.0-release and a new profile |
103 |
default-linux/x86/2005.0 would be created. This profile would never |
104 |
change. If there were multiple sets of stages created, such as the |
105 |
amd64 release for 2004.2, which will have both gcc 3.3 and gcc 3.4 |
106 |
stages, a sub-profile would be created, |
107 |
default-linux/amd64/2005.0/gcc34. |
108 |
|
109 |
At this point, the -release tree is turned over to -releng and the arch |
110 |
leads/maintainers for preparation for the impending release. If changes |
111 |
are needed that only affect the LiveCD/GRP, they go into the tree |
112 |
directly. If changes are needed that affect the package as a whole, the |
113 |
package maintainer is contacted, and the package is fixed in both the |
114 |
-current and -release trees. At some point, the tree is frozen and a |
115 |
snapshot is made. This becomes the official snapshot for that release. |
116 |
A new rsync mirror set is created for the tree, and the make.globals |
117 |
SYNC is set to that new rsync mirror, |
118 |
rsync://rsync.gentoo.org/gentoo-2005.0-release/. The stages/LiveCD/GRP |
119 |
is built for the release, and everything is golden. The things that are |
120 |
marked as "stable" are never changed via rsync in this tree, as they are |
121 |
the unchanging base. The release is made, the planets align, and there |
122 |
is peace for a thousand generations... |
123 |
|
124 |
...until disaster strikes and a package has a security vulnerability. |
125 |
At this point, the package is patched, a GLSA is released, and the new |
126 |
ebuild goes into the tree as ~arch. You will notice that I have left |
127 |
out the whole "who does the updates" part of this and there is a good |
128 |
reason for it. I haven't got a clue. This would need to be decided by |
129 |
interest. After all, many people are not going to be very excited about |
130 |
applying patches to old versions of software, and that's ok. |
131 |
*** This is the weakness in not only my plan, but ANY "Enterprise |
132 |
Gentoo" plan *** |
133 |
|
134 |
|
135 |
With my method, a user can change between releases simply by overriding |
136 |
SYNC in make.conf to whatever release they wish, or even to -current. |
137 |
The upgrade would be just like doing a massive "emerge sync && emerge -u |
138 |
world" after not syncing for 6 months. Everything would upgrade |
139 |
smoothly. We would update the user's profile at sync time, too. We |
140 |
would need to include some form of logic to know whether our rsync |
141 |
mirror choice has changed, and take appropriate actions. For example, |
142 |
if I were going from 2005.0 to 2005.1 and running an amd64 with the |
143 |
gcc34 profile, if there is an amd64/2005.1/gcc34 profile, then the |
144 |
switch is simple. If amd64 has adopted gcc 3.4 as the default, then the |
145 |
profile would revert to the default. |
146 |
|
147 |
Is there anything I missed? |
148 |
|
149 |
Discuss amongst yourselves... |
150 |
|
151 |
-- |
152 |
Chris Gianelloni |
153 |
Release Engineering QA Manager/Games Developer |
154 |
Gentoo Linux |
155 |
|
156 |
Is your power animal a penguin? |