1 |
Hey, |
2 |
|
3 |
|
4 |
On Wed, 2004-07-21 at 16:00 -0400, Chris Gianelloni wrote: |
5 |
> > 4/ we will need to have a policy about how long we'll support a profile, |
6 |
> > and a procedure for end-of-lifing profiles. (probably don't want to |
7 |
> > support a single profile for more than 2 years) |
8 |
> |
9 |
> I think we had decided that a good number was 4 releases. Now, the |
10 |
> length of time for that would be determined by the release schedule, |
11 |
> naturally. The biggest problem will be our lack of manpower to back |
12 |
> port fixes. I really don't see us overcoming this problem any time |
13 |
> soon. |
14 |
|
15 |
Four releases a year is way to many.. after two years its 8 releases to |
16 |
support.. This vastly exceeds our current man-power.. Debian with its |
17 |
over 1000 devs only maintains one. One a year seems like a better |
18 |
number to me (maybe two a year). |
19 |
|
20 |
In the multiple profile scenario.. that would create possibly hundreds |
21 |
of ebuilds to be kept in the tree for a single package (one per release |
22 |
per arch and then a few unstable... thinking of a package like glibc).. |
23 |
|
24 |
|
25 |
> I can see how profiles could be used to accomplish this sort of thing, |
26 |
> but pinning of versions would not be the way to go about it. |
27 |
|
28 |
I agree |
29 |
|
30 |
|
31 |
> For simplicity, I'm going to name everything, but none of this is set in |
32 |
> stone. For one, the "gentoo-x86" CVS module would be come |
33 |
> "gentoo-current", as it reflects the actual usage and state of the |
34 |
> tree. The profiles in the current tree would have their versions |
35 |
> removed, as this is a fluid target. This matches our current tree the |
36 |
> best, and allows for us to make dynamic changes to the profiles between |
37 |
> releases. For example, default-x86-2005.0 (or |
38 |
> default-linux/x86/2005.0), would become default-linux/x86/current. Each |
39 |
> release tree would be identified as such. I'm going to work with |
40 |
> cascading profiles, to make my life easier. At release time, a branch |
41 |
> is made for the release. We would take the stable ebuilds/packages from |
42 |
> gentoo-current and drop it into gentoo-2005.0-release and a new profile |
43 |
> default-linux/x86/2005.0 would be created. This profile would never |
44 |
> change. If there were multiple sets of stages created, such as the |
45 |
> amd64 release for 2004.2, which will have both gcc 3.3 and gcc 3.4 |
46 |
> stages, a sub-profile would be created, |
47 |
> default-linux/amd64/2005.0/gcc34. |
48 |
> |
49 |
> At this point, the -release tree is turned over to -releng and the arch |
50 |
> leads/maintainers for preparation for the impending release. If changes |
51 |
> are needed that only affect the LiveCD/GRP, they go into the tree |
52 |
> directly. If changes are needed that affect the package as a whole, the |
53 |
> package maintainer is contacted, and the package is fixed in both the |
54 |
> -current and -release trees. At some point, the tree is frozen and a |
55 |
> snapshot is made. This becomes the official snapshot for that release. |
56 |
> A new rsync mirror set is created for the tree, and the make.globals |
57 |
> SYNC is set to that new rsync mirror, |
58 |
> rsync://rsync.gentoo.org/gentoo-2005.0-release/. The stages/LiveCD/GRP |
59 |
> is built for the release, and everything is golden. The things that are |
60 |
> marked as "stable" are never changed via rsync in this tree, as they are |
61 |
> the unchanging base. The release is made, the planets align, and there |
62 |
> is peace for a thousand generations... |
63 |
|
64 |
I like the idea of a separate tree.. But if it really rarely changes, |
65 |
rsync is just overkill and will overburden our mirrors.. Lets just make |
66 |
it a tarball and put the enhancements in a rsync'ed overlay. Rsync is |
67 |
for stuff that changes... |
68 |
|
69 |
|
70 |
> ...until disaster strikes and a package has a security vulnerability. |
71 |
> At this point, the package is patched, a GLSA is released, and the new |
72 |
> ebuild goes into the tree as ~arch. You will notice that I have left |
73 |
> out the whole "who does the updates" part of this and there is a good |
74 |
> reason for it. I haven't got a clue. This would need to be decided by |
75 |
> interest. After all, many people are not going to be very excited about |
76 |
> applying patches to old versions of software, and that's ok. |
77 |
> *** This is the weakness in not only my plan, but ANY "Enterprise |
78 |
> Gentoo" plan *** |
79 |
|
80 |
This overlays should probably each have their own cvs module (or all be |
81 |
directories under the same module, I dont really care... Where all |
82 |
package maintainers would have access.. And then we can mark them stable |
83 |
using the same kind of procedures we currently use for GLSAs... |
84 |
|
85 |
Also, the problem with maintaining older versions is that we need to |
86 |
have at least one machine available for each version where the concerned |
87 |
devs can test security updates.. Ok, maybe at least one per |
88 |
architectures using chroots... but its still a lot of infrastructure.. |
89 |
That's why reducing the number of stable releases to maybe even just one |
90 |
a year might be a good idea. |
91 |
|
92 |
|
93 |
|
94 |
-- |
95 |
Olivier Crête |
96 |
tester@g.o |
97 |
Gentoo Developer |
98 |
|
99 |
|
100 |
-- |
101 |
gentoo-dev@g.o mailing list |