public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: Sven Eckelmann <sven.eckelmann@gmx.de>
Cc: b.a.t.m.a.n@lists.open-mesh.net
Subject: Re: [B.A.T.M.A.N.] [PATCH 00/26] Staging: batman-adv
Date: Sat, 22 May 2010 08:27:12 -0700	[thread overview]
Message-ID: <20100522152712.GA4671@suse.de> (raw)
In-Reply-To: <201005221708.45102.sven.eckelmann@gmx.de>

On Sat, May 22, 2010 at 05:08:44PM +0200, Sven Eckelmann wrote:
> Greg KH wrote:
> > On Sat, May 22, 2010 at 04:16:45PM +0200, Sven Eckelmann wrote:
> > > Hi,
> > > 
> > > we've tried to fix the outstanding problem regarding the sysfs filesystem
> > > and fixed some further smaller problems. I hope that it is right were we
> > > put the ABI documentation.
> > 
> > Not really, but I responded to where it should go on that message.
> 
> Thanks. I will move them to the right place.
> 
> > As we are now past the .35 merge window, you should consider what
> > patches should be acceptable for the .35 release, and which should wait
> > until .36.  It looks like about half of these patches should be queued
> > up for .35 as they are bug fixes, right?  The api changes by moving
> > stuff into debugfs should wait for .36.
> 
> The merge window is already closed? v2.6.34 was released 6 days ago. Or do you 
> mean that your merge window for staging is closed?

The merge window is for the subsystem maintainers to send stuff to
Linus.  That stuff must have already been in the linux-next tree for a
bit to test it out and ensure that it doesn't break anyone.

So that means that you need to get things to the subsystem maintainers a
week or so before the merge window opens up if you want to see it go
into the next kernel release.

And yes, this means the merge window for the staging tree for new
features is now closed.  Only bugfixes will be accepted for .35 from now
on, but I can easily queue up stuff for .36, I just have to wait until
.35-rc1 is out before I can add it to my public tree for inclusion in
the linux-next tree.

Hope this explains things a bit better.

greg k-h

  reply	other threads:[~2010-05-22 15:27 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-22 14:16 [B.A.T.M.A.N.] [PATCH 00/26] Staging: batman-adv Sven Eckelmann
2010-05-22 14:17 ` [B.A.T.M.A.N.] [PATCH 01/10] Staging: batman-adv: remove redundant struct declaration Sven Eckelmann
2010-05-22 14:17 ` [B.A.T.M.A.N.] [PATCH 02/10] Staging: batman-adv: fix rogue packets on shutdown Sven Eckelmann
2010-05-22 14:17 ` [B.A.T.M.A.N.] [PATCH 03/10] Staging: batman-adv: Call unregister_netdev on failures to get rtnl lock Sven Eckelmann
2010-05-22 14:17 ` [B.A.T.M.A.N.] [PATCH 04/10] Staging: batman-adv: Don't call free_netdev twice Sven Eckelmann
2010-05-22 14:17 ` [B.A.T.M.A.N.] [PATCH 05/10] Staging: batman-adv: Move device for icmp injection to debugfs Sven Eckelmann
2010-05-22 14:17 ` [B.A.T.M.A.N.] [PATCH 06/10] Staging: batman-adv: Move tables from sysfs " Sven Eckelmann
2010-05-22 14:17 ` [B.A.T.M.A.N.] [PATCH 07/10] Staging: batman-adv: Don't allocate icmp packet with GFP_KERNEL Sven Eckelmann
2010-05-22 14:17 ` [B.A.T.M.A.N.] [PATCH 08/10] Staging: batman-adv: convert all sysfs files to single value files Sven Eckelmann
2010-05-22 14:17 ` [B.A.T.M.A.N.] [PATCH 09/10] Staging: batman-adv: Adding netfilter-bridge hooks Sven Eckelmann
2010-05-22 14:17 ` [B.A.T.M.A.N.] [PATCH 10/10] Documentation: ABI: Add information about batman-adv sysfs entries Sven Eckelmann
2010-05-22 14:32   ` Greg KH
2010-05-22 15:01     ` Sven Eckelmann
2010-05-22 14:35 ` [B.A.T.M.A.N.] [PATCH 00/26] Staging: batman-adv Greg KH
2010-05-22 15:08   ` Sven Eckelmann
2010-05-22 15:27     ` Greg KH [this message]
2010-05-22 15:32       ` Sven Eckelmann
2010-05-24 18:43         ` Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2010-05-06 20:18 [B.A.T.M.A.N.] [PATCH 00/26] staging:batman-adv Andrew Lunn
2010-05-06 21:44 ` Sven Eckelmann
2010-05-07  3:14   ` Marek Lindner
2010-05-07 10:48     ` Sven Eckelmann
2010-05-07  5:25   ` Andrew Lunn

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=20100522152712.GA4671@suse.de \
    --to=gregkh@suse.de \
    --cc=b.a.t.m.a.n@lists.open-mesh.net \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    --cc=sven.eckelmann@gmx.de \
    /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