Re: [gentoo-dev] Revisiting GLEP 19

[Chris Gianelloni <wolf31o2@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3882 bytes --]

On Tue, 2004-07-20 at 21:55, Barry Shaw wrote:
> It might be worth considering instead a model where a snapshot is taken
> then only security patches are applied, with the exception that should a
> particular version of an application become depreciated, it can then
> also be upgraded (provided the upgraded version is also considered stable).

I would have no problem with this, provided it was the up-front decision
and we stuck to it.  It would still fit in with my (rather lengthy)
proposal, and would reduce the developer overhead significantly.

> This would enable snapshots to last for a longer period (I think four a
> year is going to be too much work), it prevents any requirement for
> backporting (which I think is a bad idea as it makes ebuild maintainers
> into application maintainers) and it would also make the maintenence of
> older snapshots more viable as there would be less work to do in general.

I think 2 a year with a 2 year retention (4 releases) would be the sweet
spot.  Nothing keeps users from running older releases, just we don't
support them officially any more.

> Some of the current discussion on the length of time snapshots are
> maintained is concerning as production servers, in my experience, remain
> in the same state for years - a one year maintenence period is not long
> enough (it would be for workstations however as these are easier to take
> out of service for an hour or so and upgrade).

What about Red Hat (think RHL, not RHEL)?  They only ever supported I
believe 2 releases back and had a release approximately every six
months.  At the same time, there are many servers out there that still
run 7.3 and even 6.2 and work perfectly fine.  Depending on their
function, they may be completely secure, also.  It is not that difficult
to write an ebuild.  Nothing is stopping a user from importing an ebuild
from the -current tree or any other -release tree into their overlay for
an upgrade.  We simply have to put a limit on how far back we support,
especially as we are a community-based distribution.

> In reality, if a application on a production server reaches a state
> where it is unmaintained in favour of a newer version, then its likely
> that the admins would upgrade the application to the supported version.
> ~ Most responsible program maintainers provide upgrade paths anyways, so
> as long non security related package upgrade wasn't forced on
> subscribers to the stable tree, it shouldn't be too bad.  At the least
> if such a change could be signalled, people would be prepared.

My thinking exactly.  With frozen package versions in the -release
trees, a company could evaluate whether their software operated as
expected on the new release.  Also, since we would be providing a simple
upgrade path, it would ease the workload on administrators using
"Enterprise Gentoo".

> I guess what I'm describing isn't strictly an enterprise gentoo (which I
> don't think the community has the resources to support), more of a
> slowed down version of the main portage tree.  In my experience
> maintaining a couple of hundred of gentoo machines centrally, its the
> rapid pace of change in the main tree that causes problems.  We only
> only upgrade packages for security reasons, but whenever we do this, we
> are forced to upgrade a multitude of other packages because they've
> dropped out of portage.  If we only had to upgrade packages for security
> and depreciation reasons it would make for a much more stable
> environment for the end users (which is what we're after ultimately) and
> ~ it would make maintenence more manageable.

I agree that there is no real need for an Enterprise Gentoo, but rather
fixed releases.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]