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 |