public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.

      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