From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Paul Gortmaker <paul.gortmaker@gmail.com>
Cc: Jean Delvare <khali@linux-fr.org>,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: linux-next: rebase of the jdelvare-hwmon quilt series
Date: Fri, 12 Jul 2013 10:27:59 +1000 [thread overview]
Message-ID: <20130712102759.7bc9e68271b1b0ad6b0f4fdd@canb.auug.org.au> (raw)
In-Reply-To: <CAP=VYLrNH8pZJUPyfZCtLGGQn_ZcBWbNynSHrwYpeKmqqE6Bsg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]
Hi Jean,
On Thu, 11 Jul 2013 19:17:52 -0400 Paul Gortmaker <paul.gortmaker@gmail.com> wrote:
>
> On Thu, Jul 11, 2013 at 3:39 AM, Jean Delvare <khali@linux-fr.org> wrote:
> >
> > FWIW I would have accepted the patch even if it was not trivial and it
> > would have gone in linux-next just the same. The only difference is
> > whether I consider the patch for this merge window or only for the next.
>
> The linux-next tree should not see "new" commits during the two week
> window of the merge window -- only content for the active merge window
> should be in linux-next during the merge window. Once the rc1 tag has
> been completed, then you can add new content. This has been something
> that Stephen broadcasts regularly for each merge window start.
>
> So there is nothing wrong with accepting the patch, but if it isn't destined
> for this merge window, then it should not be forwarded to linux-next until
> after rc1 gets tagged.
>
> > Is there a policy to not include new patches in linux-next during a
> > merge window if the patch is for the next merge window? If so I wasn't
> > aware of it. I always considered that the earlier a patch gets in
> > linux-next, the better.
>
> Yes, see above.
As Paul said, new material should not enter linux-next until after -rc1
is released. In fact, every time Linus opens a merge window, I send an
email to lkml and the linux-next list saying just that. I also often add
that message to the top of my daily release announcements (though I
forgot during this merge window).
This restriction is imposed so that maintainers still getting their code
into the current merge window are not distracted by reports of problems
in linux-next to do with code that will not be merged in this merge
window.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2013-07-12 0:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-11 0:27 linux-next: rebase of the jdelvare-hwmon quilt series Stephen Rothwell
2013-07-11 5:57 ` Jean Delvare
2013-07-11 6:53 ` Stephen Rothwell
2013-07-11 7:39 ` Jean Delvare
2013-07-11 23:17 ` Paul Gortmaker
2013-07-12 0:27 ` Stephen Rothwell [this message]
2013-07-12 0:36 ` Stephen Rothwell
2013-09-05 0:19 Stephen Rothwell
2013-09-05 7:25 ` Jean Delvare
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=20130712102759.7bc9e68271b1b0ad6b0f4fdd@canb.auug.org.au \
--to=sfr@canb.auug.org.au \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=paul.gortmaker@gmail.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;
as well as URLs for NNTP newsgroup(s).