Messages in this thread | | | From | devnull@spaans ... | Date | Wed, 13 Sep 2000 10:32:03 -0400 | Subject | Re: Proposal: Linux Kernel Patch Management System |
| |
Date: Wed, 13 Sep 2000 03:30:39 -0700 From: "David S. Miller" <davem@redhat.com>
From: Daniel Quinlan <quinlan@transmeta.com> 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 fixed.
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 work.
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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |