Theodore Y. Ts'o writes:
> 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.
Something I've been planning on implementing for some time now is a
small patch to patch, so that it recognises lines of the form:
Notify: email,id
in a patch, then an email is sent to <email> stating that a patch with
ID <id> has been applied. This would allow for automatic notification
of the patch author when their patch has been applied. All that is
needed is for Linus to update his patch binary.
This way, I wouldn't have to sift through a diff to see if my patch
has been applied. And it doesn't require any change in the way Linus
works. An extension which does change the way he works would involve
him running a patch --reject on a patch before hitting 'd'.
And possibly also a patch --not-now.
It also doesn't require developers to change their habits. It's
entirely optional.
Separately, making Linus' unpacked working trees available:
ftp://ftp.??.kernel.org/pub/linux/kernel/v*/LIVE/
would make patch generation a lot easier.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:21 EST