| 1 |
On Monday 09 August 2004 08:34, Greg KH wrote: |
| 2 |
> On Sun, Aug 08, 2004 at 06:51:44PM +0000, Kurt Lieber wrote: |
| 3 |
> > Third, many folks want long-term support of these releases. I |
| 4 |
> > *don't* think this is viable and am not willing to personally sponsor |
| 5 |
> > this. A core component of this GLEP is that we will *not* be |
| 6 |
> > backporting security fixes. |
| 7 |
> |
| 8 |
> So what would happen for security fixes? Rely on the latest release |
| 9 |
> from upstream to be used instead? This can cause real problems, as a |
| 10 |
> lot of SATA users just found out with the most recent Fedora kernel |
| 11 |
> update due to the security fix. They went with the most recent kernel, |
| 12 |
> which happened to rename their disk drives. |
| 13 |
|
| 14 |
Testing is of course necessary. At each time it needs to be considered |
| 15 |
whether backporting or upgrading is the best way to go. In many cases |
| 16 |
backporting only amounts to isolating the changes to the current ebuild |
| 17 |
and applying that patch to the old version. One needs some knowledge of |
| 18 |
the programming language used to judge the probable impact but for many |
| 19 |
patches one can be quite confident that the impact is minimal. |
| 20 |
|
| 21 |
> |
| 22 |
> What is the downside of just backporting the security fixes to the |
| 23 |
> versions marked "stable" (becides developer time)? I really think this |
| 24 |
> is something most people who want a "stable" tree will want to have (if |
| 25 |
> for no other reason than that's how all the other Linux distros do it, |
| 26 |
> and it will take less effort trying to explain why we don't...) |
| 27 |
|
| 28 |
I agree that discounting backporting in advance might not be the best way |
| 29 |
to go. But I agree that our backporting resources are very limited. |
| 30 |
|
| 31 |
Paul |
| 32 |
|
| 33 |
-- |
| 34 |
Paul de Vrieze |
| 35 |
Gentoo Developer |
| 36 |
Mail: pauldv@g.o |
| 37 |
Homepage: http://www.devrieze.net |
Archives