[lkml]   [2000]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Proposal: Linux Kernel Patch Management System
   Date: 	Wed, 13 Sep 2000 03:30:39 -0700
From: "David S. Miller" <>

From: Daniel Quinlan <>
Date: Wed, 13 Sep 2000 03:18:14 -0700 (PDT)

How exactly does a system to tracking patches and bugs/fixes (not to
mention helping Linus and Ted) not help developers?

It has the potential to make more work for those of us who do our
patch submissions effectively already.

How can we simplify things? Part of the design of this new proposal was
to change as little as possible from the existing setup (people's habits
are hard to change), and yet to make my life and Linus's life much
easier. In the long run, it will make your life easier, to the extent
that having an up-to-date bug list is easier, and because then I won't
have to continually pester people about whether certain bugs have been

Right now, having to paw through diff files to see when Linus has
applied a particular patch (add grumble about lack of a source code
control system) is really not fun. Alan did it for a while, and burned
out, and I can tell you, I can't really blame him --- it's a lot of

Is it really that hard to annotate the patch with a bit of information,
and then send it off to a different mailing address instead of sending
it directly to Linus and the l-k list?

What can we do to make things simpler on developers? Certainly this
isn't going to work unless the developers use it, and that means we need
to keep things as easy as possible for the patch submitters.

- Ted

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.084 / U:0.972 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site