[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: kernel-patch-amd64



On Thu, Jul 08, 2004 at 02:34:55PM +0900, Horms wrote:
> On Wed, Jul 07, 2004 at 09:46:15PM +0200, Sven Luther wrote:
> > On Wed, Jul 07, 2004 at 02:05:37PM -0500, Troy Benjegerdes wrote:
> > > On Sat, Jul 03, 2004 at 10:48:10PM +0200, Sven Luther wrote:
> > > > On Sat, Jul 03, 2004 at 07:40:49PM +0200, Christoph Hellwig wrote:
> > > > > On Fri, Jul 02, 2004 at 03:32:55PM +0200, Goswin von Brederlow wrote:
> > > > > > Its also quite off the mark for amd64. The last kerel version had a 0 Byte
> > > > > > patch for amd64 and only the current one has some patches in there to
> > > > > > fix recent bugs.
> > > > > 
> > > > > So what exact problems does the patch you propose solve?  Which systems
> > > > > don't boot/corrupt data/start nuclear wars without it?   Do you
> > > > > understand what exactly the patch does?
> > > > 
> > > > Well, Christoph, i have trouble understanding all this religiuous anti
> > > > patch problem. As in the case of the Marvell driver, what is the problem
> > > > in having the patch as is available to debian/unstable users, _WHILE_ we
> > > > are working on cleaning the situation ? Also, again if the last kernel
> > > > version (2.6.6) had a obyte patch, and the current one (2.6.7) has only
> > > > bug fixes, it is more than probable that those patches will also be
> > > > submitted upstream pretty soon.
> > > 
> > > If someone (in this case Christoph and Viro) isn't around continually
> > > trying to get people to submit upstream, the users lose out because the
> > > patch(es) never get submitted and rot. Or it just keeps getting bigger and
> > > bigger and never gets reviewed.
> > 
> > I doubt this applies in this case though.
> > 
> > > In the amd64 case, I haven't seen anyone point out what kernel.org 2.6.7 is 
> > > missing that the big amd64 patch misses.
> > 
> > Probably 2.6.8 development branch fixes and backports ? 
> 
> I believe that statement is a strong argument for splitting 
> up the patches, so their purpose can more easily be determined. 
> Though in this cause they likely would not need to be pushed upstream.

Sure, but i believe that at this point getting the various other kernel
port patch maintainers into the debian-kernel team is more important a
goal, and it is not by yelling on them that this will happen.

Friendly,

Sven Luther



Reply to: