| 1 |
On Mon, Aug 09, 2004 at 09:46:06AM +0200, Paul de Vrieze wrote: |
| 2 |
> On Monday 09 August 2004 08:34, Greg KH wrote: |
| 3 |
> > On Sun, Aug 08, 2004 at 06:51:44PM +0000, Kurt Lieber wrote: |
| 4 |
> > > Third, many folks want long-term support of these releases. I |
| 5 |
> > > *don't* think this is viable and am not willing to personally sponsor |
| 6 |
> > > this. A core component of this GLEP is that we will *not* be |
| 7 |
> > > backporting security fixes. |
| 8 |
> > |
| 9 |
> > So what would happen for security fixes? Rely on the latest release |
| 10 |
> > from upstream to be used instead? This can cause real problems, as a |
| 11 |
> > lot of SATA users just found out with the most recent Fedora kernel |
| 12 |
> > update due to the security fix. They went with the most recent kernel, |
| 13 |
> > which happened to rename their disk drives. |
| 14 |
> |
| 15 |
> Testing is of course necessary. At each time it needs to be considered |
| 16 |
> whether backporting or upgrading is the best way to go. In many cases |
| 17 |
> backporting only amounts to isolating the changes to the current ebuild |
| 18 |
> and applying that patch to the old version. One needs some knowledge of |
| 19 |
> the programming language used to judge the probable impact but for many |
| 20 |
> patches one can be quite confident that the impact is minimal. |
| 21 |
|
| 22 |
Also realize that we almost always have access to just the security |
| 23 |
patch that is needed, because this is what other distros do. So it's |
| 24 |
not usually a case that we need to create the patches ourselves for |
| 25 |
this. |
| 26 |
|
| 27 |
thanks, |
| 28 |
|
| 29 |
greg k-h |
| 30 |
|
| 31 |
-- |
| 32 |
gentoo-dev@g.o mailing list |
Archives