Gentoo Archives: gentoo-dev

From: Paul de Vrieze <pauldv@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] GLEP 19, reloaded (again)
Date: Mon, 09 Aug 2004 07:53:04
Message-Id: 200408090951.50368.pauldv@gentoo.org
In Reply to: Re: [gentoo-dev] GLEP 19, reloaded (again) by Barry Shaw
1 On Monday 09 August 2004 09:43, Barry Shaw wrote:
2 > Kurt Lieber wrote:
3 > | Second, there was some question about how often the tree would be
4 > | updated. The GLEP doesn't really specify this, but I think once a
5 > | year is a reasonable timeframe.
6 > |
7 > | Third, many folks want long-term support of these releases. I
8 > | *don't* think this is viable and am not willing to personally sponsor
9 > | this. A
10 >
11 > core
12 >
13 > | component of this GLEP is that we will *not* be backporting security
14 >
15 > fixes.
16 >
17 > | (at least not as a rule) We will be relying on the versions that the
18 > | original authors provide except in very unusual circumstances. The
19 > | reason for this is simple -- we don't have the resources to guarantee
20 > | that we can backport things (and, more importantly, guarantee that
21 > | they'll work right once backported) Suppporting a profile for four
22 > | or more years almost guarantees you'll be doing a lot of backporting.
23 > | I don't plan to incorporate long-term support as part of this GLEP.
24 > | That might, however, be an excellent opportunity for commercial
25 > | companies with greater finanial resources than us.
26 >
27 > My main concern here is that if you've got a core server, which
28 > typically has lifetime of 3 to 4 years, you don't want to be
29 > reinstalling it every year (in many cases you can't). That said, I
30 > agree that its unlikely there are resources to maintain a tree for
31 > years on end. As a compromise, if some consideration was given to
32 > easing migration, that would be suitable. Given the fact that servers
33 > have a very minimal level of software on them anyway, its probably not
34 > too much of a big deal.
35
36 The upgrade is not supposed to be a reinstall. Just an upgrade, allthough
37 there might be some issues with configuration files etc.
38
39 > Backporting has been mentioned in Greg k-h's post and I think thats
40 > something we want to stay away from. Ebuild maintainers may not have
41 > the programming skill necessary to backport fixes from one version of
42 > the software to another. The upstream maintainers are the experts in
43 > that respect and thats where that decision should stay. In my
44 > experience once the upstream maintainer stops maintaining a certain
45 > version of the software, migration to the new version is necessary
46 > anyway.
47
48 I don't think it is wise to make a black-and-white decision beforehand. Of
49 course we need some general guideline though.
50
51 >
52 > The other downside to backporting is that it causes tonnes of false
53 > positives if you do any proactive network scanning. Not a major
54 > really, but its one of my pet hates 8)
55
56 That's not really a fair issue. If it is an issue the version number could
57 be ammended.
58
59 --
60 Paul de Vrieze
61 Gentoo Developer
62 Mail: pauldv@g.o
63 Homepage: http://www.devrieze.net