public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: ebiederm@xmission.com (Eric W. Biederman)
Cc: torvalds@osdl.org, pavel@suse.cz, len.brown@intel.com,
	drzeus-list@drzeus.cx, acpi-devel@lists.sourceforge.net,
	ncunningham@cyclades.com, masouds@masoud.ir,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] suspend: Cleanup calling of power off methods.
Date: Wed, 21 Sep 2005 11:02:01 -0700	[thread overview]
Message-ID: <20050921110201.1cc7fca2.akpm@osdl.org> (raw)
In-Reply-To: <m1slvycotk.fsf@ebiederm.dsl.xmission.com>

ebiederm@xmission.com (Eric W. Biederman) wrote:
>
> Linus Torvalds <torvalds@osdl.org> writes:
> 
> > On Wed, 21 Sep 2005, Pavel Machek wrote:
> >> 
> >> I think you are not following the proper procedure. All the patches
> >> should go through akpm.
> 
> Ok.  I thought it was fine to send simple and obviously correct bug
> fixes to Linus.

I habitually scoop up patches and will get them into Linus (preferably
after 1-2 -mm cycles) if he ducks them.

> > One issue is that I actually worry that Andrew will at some point be where 
> > I was a couple of years ago - overworked and stressed out by just tons and 
> > tons of patches. 
> >
> > Yes, he's written/modified tons of patch-tracking tools, and the git 
> > merging hopefully avoids some of the pressures, but it still worries me. 
> > If Andrew burns out, we'll all suffer hugely.
> >
> > I'm wondering what we can do to offset those kinds of issues. I _do_ like 
> > having -mm as a staging area and catching some problems there, so going 
> > through andrew is wonderful in that sense, but it has downsides.
> 
> It is especially challenging for people like me who typically work on
> parts of the kernel without a maintainer.  So there frequently isn't
> an intermediate I can submit my patches to.

Yup.  And MAINTAINERS has quite a few omissions.  I generally know who
should be poked and if there's nobody obvious I have 26000 patches to grep
through to find out who might know a bit about that code.  Low-level x86 is
a bit of a problem really because it has many cooks and no obvious chef.

Individual maintainers have differing response times, differing
attentiveness and differing patchloss ratios.

There's also confusion once I've cc'ed a maintainer on a patch over whether
I'll be sending it to Linus or whether I want them to.

If a maintainer has a tree in -mm then I'll autodrop the patch if they
merge it, so there's no confusion there.

If the maintainer says "thanks, merged" and I don't have their tree in -mm
then I'll tend to hang onto the patch indefinitely until it finally hits
-linus.  Or I'll eventually forget and merge it up anyway ;) 

If the maintainer just acks the patch I'll send it in to Linus.

If the maintainer nacks the patch I'll either drop it or I'll mark it
not-for-merging and hang onto it anwyay, as a reminder that we have some
bug which needs fixing.

If the maintainer has a tree in -mm and doesn't merge the patch I'll hang
onto it and periodically resend to the maintainer until some definite
response comes back.


  reply	other threads:[~2005-09-21 18:03 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-01 18:23 reboot vs poweroff Brown, Len
2005-09-02  4:43 ` Eric W. Biederman
2005-09-10 21:07 ` Eric W. Biederman
2005-09-11  8:43   ` Meelis Roos
2005-09-11  8:53     ` Eric W. Biederman
2005-09-20 17:42     ` [PATCH 1/2] reboot: Comment and factor the main reboot functions Eric W. Biederman
2005-09-20 17:49       ` [PATCH 2/2] suspend: Cleanup calling of power off methods Eric W. Biederman
2005-09-20 21:06         ` Pavel Machek
2005-09-21  2:08           ` Eric W. Biederman
2005-09-21 10:18             ` Pavel Machek
2005-09-21 13:50               ` Eric W. Biederman
2005-09-21 16:35               ` Linus Torvalds
2005-09-21 17:28                 ` Eric W. Biederman
2005-09-21 18:02                   ` Andrew Morton [this message]
2005-09-21 17:36                 ` Alexander Nyberg
2005-09-21 18:15                   ` Andrew Morton
2005-09-21 19:45                     ` Hugh Dickins
2005-09-21 18:35                   ` Diego Calleja
2005-09-21 18:49                     ` Andrew Morton
2005-09-21 19:54                       ` Martin J. Bligh
2005-09-26 12:09                         ` Diego Calleja
2005-09-26 13:47                           ` Martin J. Bligh
2005-09-21 20:16                       ` Diego Calleja
2005-09-21 19:43                   ` Russell King
2005-09-21 20:10                     ` Andrew Morton
2005-09-22  7:15                     ` Pierre Ossman
2005-09-22  8:10                       ` [ACPI] " Rafael J. Wysocki
2005-09-22  9:30                       ` Eric W. Biederman
2005-09-22  9:38                         ` Russell King
2005-09-22 10:54                         ` Pierre Ossman
2005-09-21 17:46                 ` Andrew Morton
2005-09-21 18:08                   ` Eric W. Biederman
2005-09-21 18:24                     ` Andrew Morton

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=20050921110201.1cc7fca2.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=acpi-devel@lists.sourceforge.net \
    --cc=drzeus-list@drzeus.cx \
    --cc=ebiederm@xmission.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masouds@masoud.ir \
    --cc=ncunningham@cyclades.com \
    --cc=pavel@suse.cz \
    --cc=torvalds@osdl.org \
    /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