From: Rusty Russell <rusty@rustcorp.com.au>
To: Dave Jones <davej@suse.de>
Cc: linux-kernel@vger.kernel.org, torvalds@transmeta.com,
marcelo@conectiva.com.br
Subject: Re: Trivial Patch Policy (trivial@rustcorp.com.au)
Date: Wed, 14 Aug 2002 13:56:02 +1000 [thread overview]
Message-ID: <20020813225913.8F8CE2C205@lists.samba.org> (raw)
In-Reply-To: Your message of "Tue, 13 Aug 2002 18:52:33 +0200." <20020813185233.J13598@suse.de>
In message <20020813185233.J13598@suse.de> you write:
> On Mon, Aug 12, 2002 at 05:07:05PM +1000, Rusty Russell wrote:
> > 2) The patch will not be forwarded to anyone until a new kernel has
> > been released after I receive the patch, *unless* noone else is
> > sent the patch. So if you cc: the trivial patch monkey, it'll only
> > be forwarded from there if it doesn't make the next kernel.
>
> What happens in this case..
>
> person a sends the monkey a patch.
> person b replies to l-k (cc'ing monkey) with a "no do it this way" ?
>
> do you have a hand-operated means to say "this patch supercedes the
> previous" ?
Yes, I close the old patch, and add the new one. Low-tech, I know 8).
The original person will get a one-liner on why the patch was closed
(like, "obsoleted by new patch").
> > 3) The first time the patch is forwarded, it will be sent to the
> > author and/or maintainer. If they say they've included it in their
> > tree, no more forwards will occur (modulo some timeout eventually).
> > If they NAK it, the patch will be closed. Otherwise, the patch
> > will be sent directly to Linus or Marcelo on future forwards (the
> > maintainer will still be cc'd).
>
> What would be *really* good, for the case where retransmits are
> necessary, if Alan hasn't picked it up for 2.4 (or me for 2.5),
> you could add us to the relevant Cc's, (and remove after Alan/Myself
> takes it).
Hmmm, but it also adds the "multiple path to Linus problem" (yeah, I
could use BK, and I could start using Borland compilers too).
I currently don't track -ac and -dj trees at all, so I'd have to add
them. It's certainly possible.
> This could however get tricky, as the same patch may need a bit
> of hand-merging to fit against -ac/-dj.
That's something I've simply refused to get into: patches either apply
or they don't. With about 40 patches a week and other
responsibilities, I rely on the author seeing that something broke and
retransmitting.
> Maybe just simpler to remove us when Alan/I send an ACK ?
In total, I'm not convinced it's worth the effort.
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
prev parent reply other threads:[~2002-08-14 3:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-12 7:07 Trivial Patch Policy (trivial@rustcorp.com.au) Rusty Russell
2002-08-13 16:52 ` Dave Jones
2002-08-14 3:56 ` Rusty Russell [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020813225913.8F8CE2C205@lists.samba.org \
--to=rusty@rustcorp.com.au \
--cc=davej@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox