1 |
On Thu, 2004-07-22 at 05:00, Duncan wrote: |
2 |
> Chris Gianelloni posted <1090441261.19552.124.camel@localhost>, excerpted |
3 |
> below, on Wed, 21 Jul 2004 16:21:01 -0400: |
4 |
> |
5 |
> > I think 2 a year with a 2 year retention (4 releases) would be the sweet |
6 |
> > spot. Nothing keeps users from running older releases, just we don't |
7 |
> > support them officially any more. |
8 |
> |
9 |
> First, I'm a personal desktop user who migrated to Gentoo in large part |
10 |
> for its "freshness". Thus, the very idea of slowing things down seems |
11 |
> counter to the entire Gentoo thing, here, tho I understand the enterprise |
12 |
> need, and the appeal of a Gentoo Linux Enterprise. If it's going to be |
13 |
> done, in some ways, I think some other name might be more appropriate, tho |
14 |
> if it's based on Gentoo, the other side says it's entirely appropriate. |
15 |
|
16 |
Who cares what the name would be right now, since nobody's even agreed |
17 |
on whether to do it or not... ;] |
18 |
|
19 |
Personally, I don't like the idea of calling it "Enterprise" at all, |
20 |
simply because it implies a certain amount of support that I don't |
21 |
believe that we can provide. I would think our best naming would simply |
22 |
be to refer to it by the actual release. The 2005.0 release would be |
23 |
"Gentoo Linux 2005.0". There's no need to add any additional moniker to |
24 |
the name, especially one that would imply a level of enterprise-class |
25 |
support, such as that provided by Red Hat, SuSE, or Mandrake to their |
26 |
enterprise customers. We won't have somebody that can be called up on |
27 |
the phone. We won't have that level of support, so we shouldn't give |
28 |
anyone the impression that we do. |
29 |
|
30 |
> Anyway.. I replied here in particular, because I wanted to comment on the |
31 |
> point quoted. From my observation of the commercial distribs and their |
32 |
> reaction to Enterprise, as well as business reaction to their enterprise |
33 |
> products, both the six month window and the two year window are to short. |
34 |
|
35 |
We aren't a commercial distribution. We can't pretend to be one, nor at |
36 |
like one. Instead, we should act as we are, a community-based |
37 |
distribution of volunteers who strive to release the best product that |
38 |
we can with the resources we're given. |
39 |
|
40 |
I'm not sure if I agree with the windows being too short, but I'm not |
41 |
going to discount it, either. After all, we're simply discussing here. |
42 |
|
43 |
> If it's to be based on Gentoo Linux with its current quarterly releases*, |
44 |
> it /would/ seem a multiple of that would be a good idea, and an annual one |
45 |
> sounds like just to big a deal, to much invested. Thus, I'd propose |
46 |
> a tri-release multiple rather than every other release, for a nine-month |
47 |
> Enterprise release cycle rather than six. The first three months of the |
48 |
> cycle could then be devoted to mostly supporting upgrades. The second |
49 |
> three months would be focused on choosing and stabilizing a snapshot. |
50 |
> This would offer a choice of two normal snapshot versions in case one had |
51 |
> been found to be less than optimal, plus the possibility of an intervening |
52 |
> version of individual packages if necessary. At the six-month point, a |
53 |
> pre-release (aka Gentoo Enterprise Community) would be produced, which |
54 |
> enterprise users could then start validating, with the full release |
55 |
> (Gentoo Enterprise Official) three months later, incorporating any fixes |
56 |
> necessary during the three month early validation period. This would also |
57 |
> allow a bit more room for vacations and various other short term breaks of |
58 |
> a month or so, where such might crimp a six-month release cycle (and |
59 |
> certainly /does/ crimp the Gentoo three-month cycle =:^( ). |
60 |
|
61 |
I could see a 9-month cycle working. The *only* problem that I see with |
62 |
this is that we've now extended the life of software well beyond our |
63 |
current means, and also well beyond what the original authors intended. |
64 |
|
65 |
> If this sounds a bit like Mandrake's community/official release policy, |
66 |
> that's no accident. They found there simply wasn't enough testing of the |
67 |
> beta and rc releases, and after a couple "dud" releases, came up with the |
68 |
> community/official release policy. Enterprises don't like "dud" releases, |
69 |
> and if we start out with something like this, I think it'll improve the |
70 |
> likelihood of Gentoo getting the reputation for solid releases. |
71 |
|
72 |
We would be less likely to have a "dud" release simply because all of |
73 |
our release material would come from our -current tree, which is pretty |
74 |
well tested, and where I believe the bulk of Gentoo's users would |
75 |
remain. |
76 |
|
77 |
> With a nine-month release cycle, that would be four releases every three |
78 |
> years. If Gentoo Enterprise supported four releases back (five releases |
79 |
> total), that would be four years of actual support, including the three |
80 |
> months of "Community" support for verification. That should be |
81 |
> comfortably enough beyond the three year general upgrade cycle that even |
82 |
> the conservative corporations should be comfortable with it, as it would |
83 |
> allow for three years of actual use, PLUS a comfortable verification and |
84 |
> conversion time at each end. |
85 |
|
86 |
Companies will tend to run software whether it is supported or not. |
87 |
Since we would not be providing a true commercial support anyway, I'm |
88 |
not sure that our support cycle would really be that important to a |
89 |
company. I think the single biggest factor *currently* with Gentoo |
90 |
being adopted in the Enterprise (or even much, much smaller shops) is |
91 |
the lack of stability in our releases, with stability meaning a static |
92 |
tree. |
93 |
|
94 |
If we provide a static tree that comes from our already tested and |
95 |
"stable" branch of our -current tree, we should have fewer bugs in it. |
96 |
If in the future, we can grow into providing back-ports and even |
97 |
commercial-grade support, then great, but we're not there now, and I |
98 |
honestly don't think we will *ever* get there if we don't take some |
99 |
action to honestly move in that direction. It's the whole concept of |
100 |
taking baby steps... learning to crawl before we can walk. |
101 |
|
102 |
> That would be comfortably more than the competition (save for Debian) |
103 |
> supports, as well. OTOH, cutting that to four releases total (three back) |
104 |
> would remain an option, and still be reasonable. |
105 |
|
106 |
I think it has always been the idea to go with 4 total (3 back) simply |
107 |
due to resources. I guess I wasn't clear on that before. |
108 |
|
109 |
> * RE: the current quarterly releases: |
110 |
> |
111 |
> IMO, these might better be three a year since all they are is snapshots |
112 |
> tested and fit for installation anyway, and don't really affect current |
113 |
> users with Gentoo already installed. This would give the arch teams and |
114 |
> releng a bit more QC time on the snapshots, and allow more ebuild |
115 |
> maintenance and development time in between releases, instead of the |
116 |
> constant focus on snapshot release stability, getting one out and having |
117 |
> to immediately start focusing on the next, with little time to focus on |
118 |
> just ebuilds/package quality itself, instead of the larger snapshot |
119 |
> quality, between release snapshots. |
120 |
|
121 |
We have a team specifically for the releases. This team does not focus |
122 |
on ebuilds at all, but the releases themselves. It is up to the ebuild |
123 |
maintainers to work on their ebuilds, as Release Engineering does not |
124 |
dictate to the maintainers what will be included. We simply do "what is |
125 |
ready". This keeps anyone from rushing something out that just isn't |
126 |
ready for the users, and also keeps pressure on the maintainers low. We |
127 |
are all volunteers, after all, and working with Gentoo can be stressful |
128 |
enough for some of us. |
129 |
|
130 |
> Or, to put it another way, it'd allow for a problem AND a vacation, in the |
131 |
> same release window, without crowding out individual package attention |
132 |
> entirely. <g> |
133 |
|
134 |
With our current system, if there's a big "problem", then we simply |
135 |
don't upgrade to the problem package(s) and stick with what worked. If |
136 |
the xfree/xorg guys decided to take a vacation for a release, it |
137 |
wouldn't kill us, as we have a perfectly working set from the last |
138 |
release. |
139 |
|
140 |
> For Enterprise, this would change the every third release, nine month |
141 |
> spacing, to every other release, eight month spacing, above, three in two |
142 |
> years, six in a four year life cycle (or five, and remain reasonably over |
143 |
> three years). |
144 |
> |
145 |
> Of course, that's just my opinion. I'm not trying to tilt at windmills, |
146 |
> wasn't yet around for the debate behind the quarterly release decision, |
147 |
> and if the current Gentoo Linux quarterly releases work.. |
148 |
|
149 |
The current release cycle seems to work. My original proposal was to |
150 |
start by keeping our current cycle, simply because it has seemed to work |
151 |
for our normal releases. Now we're talking about the introduction of a |
152 |
major change to Gentoo that affects our releases. I'm a big fan of only |
153 |
making one big change at a time. If we find it too hard to work within |
154 |
the constraints of our quarterly release cycle, then we get together and |
155 |
discuss a way to make it better. Right now, "it ain't broke", so we |
156 |
don't want to fix it... *grin* |
157 |
|
158 |
-- |
159 |
Chris Gianelloni |
160 |
Release Engineering QA Manager/Games Developer |
161 |
Gentoo Linux |
162 |
|
163 |
Is your power animal a penguin? |