1 |
On Tue, 2004-07-20 at 21:55, Barry Shaw wrote: |
2 |
> It might be worth considering instead a model where a snapshot is taken |
3 |
> then only security patches are applied, with the exception that should a |
4 |
> particular version of an application become depreciated, it can then |
5 |
> also be upgraded (provided the upgraded version is also considered stable). |
6 |
|
7 |
I would have no problem with this, provided it was the up-front decision |
8 |
and we stuck to it. It would still fit in with my (rather lengthy) |
9 |
proposal, and would reduce the developer overhead significantly. |
10 |
|
11 |
> This would enable snapshots to last for a longer period (I think four a |
12 |
> year is going to be too much work), it prevents any requirement for |
13 |
> backporting (which I think is a bad idea as it makes ebuild maintainers |
14 |
> into application maintainers) and it would also make the maintenence of |
15 |
> older snapshots more viable as there would be less work to do in general. |
16 |
|
17 |
I think 2 a year with a 2 year retention (4 releases) would be the sweet |
18 |
spot. Nothing keeps users from running older releases, just we don't |
19 |
support them officially any more. |
20 |
|
21 |
> Some of the current discussion on the length of time snapshots are |
22 |
> maintained is concerning as production servers, in my experience, remain |
23 |
> in the same state for years - a one year maintenence period is not long |
24 |
> enough (it would be for workstations however as these are easier to take |
25 |
> out of service for an hour or so and upgrade). |
26 |
|
27 |
What about Red Hat (think RHL, not RHEL)? They only ever supported I |
28 |
believe 2 releases back and had a release approximately every six |
29 |
months. At the same time, there are many servers out there that still |
30 |
run 7.3 and even 6.2 and work perfectly fine. Depending on their |
31 |
function, they may be completely secure, also. It is not that difficult |
32 |
to write an ebuild. Nothing is stopping a user from importing an ebuild |
33 |
from the -current tree or any other -release tree into their overlay for |
34 |
an upgrade. We simply have to put a limit on how far back we support, |
35 |
especially as we are a community-based distribution. |
36 |
|
37 |
> In reality, if a application on a production server reaches a state |
38 |
> where it is unmaintained in favour of a newer version, then its likely |
39 |
> that the admins would upgrade the application to the supported version. |
40 |
> ~ Most responsible program maintainers provide upgrade paths anyways, so |
41 |
> as long non security related package upgrade wasn't forced on |
42 |
> subscribers to the stable tree, it shouldn't be too bad. At the least |
43 |
> if such a change could be signalled, people would be prepared. |
44 |
|
45 |
My thinking exactly. With frozen package versions in the -release |
46 |
trees, a company could evaluate whether their software operated as |
47 |
expected on the new release. Also, since we would be providing a simple |
48 |
upgrade path, it would ease the workload on administrators using |
49 |
"Enterprise Gentoo". |
50 |
|
51 |
> I guess what I'm describing isn't strictly an enterprise gentoo (which I |
52 |
> don't think the community has the resources to support), more of a |
53 |
> slowed down version of the main portage tree. In my experience |
54 |
> maintaining a couple of hundred of gentoo machines centrally, its the |
55 |
> rapid pace of change in the main tree that causes problems. We only |
56 |
> only upgrade packages for security reasons, but whenever we do this, we |
57 |
> are forced to upgrade a multitude of other packages because they've |
58 |
> dropped out of portage. If we only had to upgrade packages for security |
59 |
> and depreciation reasons it would make for a much more stable |
60 |
> environment for the end users (which is what we're after ultimately) and |
61 |
> ~ it would make maintenence more manageable. |
62 |
|
63 |
I agree that there is no real need for an Enterprise Gentoo, but rather |
64 |
fixed releases. |
65 |
|
66 |
-- |
67 |
Chris Gianelloni |
68 |
Release Engineering QA Manager/Games Developer |
69 |
Gentoo Linux |
70 |
|
71 |
Is your power animal a penguin? |