linux-next: adding the common clk tree

Hi Stephen,

Would you please add the clk-next branch of the common clock tree to linux-next?

git://git.linaro.org/people/mturquette/linux.git clk-next

Thanks much!

For all of those Cc'd, I just wanted to say that I'm changing the way I manage clk-next. The clk-next branch now WILL be rebased, and it's only purpose is to make it easy to test things in linux-next. You can base work on it, but be prepare for breakage and shifting commit ids.

If you don't want breakage and shifting commit ids then you might want to use my clk-fixes branch (stable) and my clk-3.x branch (stable). As patches go through the linux-next cycle and appear stable I'll migrate them over to clk-3.x which won't ever be rebased. This is the branch I'll send to Linus. clk-next is simply comprised of merging clk-fixes, clk-3.x and whatever unstable patches I have laying around.

Regards,
Mike

Hi Mike,

Maybe you have misunderstood the point of linux-next (is is an integration testing tree, not a development tree)? I am wondering if, in particular, the clk-3.x branch (or something near that) may be more appropriate for linux-next inclusion (and maybe the clk-fixes branch in my "fixes to the current release" section)?

This is what I tell everyone:

You will need to ensure that the commits in your tree have been:
* submitted under GPL v2 (or later) and include the Contributor's Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary.

Cheers,
Stephen Rothwell	sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120626/6d37a3af/attachment.sig>

Hi Stephen,

Let me explain how I planned to use linux-next and you can tell me if I have it all wrong.

I had hoped to have three public branches:

clk-fixes which would be fixes for the current -rc series

clk-3.x which would be stable (never rebased) that I building up towards the next merge window

clk-next which would be the branch for you to pull

clk-next would essentially be built as the following:

git checkout clk-next
git reset --hard $linus-latest-tag
git merge clk-fixes (only if not yet merged into the -rc bugfix window) git merge clk-3.x
git am patches/clk/next/incoming/*.patch

The goal would be to move patches out of the 'incoming' directory and into clk-3.x as soon as they had made it through a couple of rounds in linux-next and no one complained that things were broken. All of this was just to keep clk-3.x very stable and not have me reverting or makings lots of little fixes to that as folks reported issues on the list.

In fact, my goal is that the 'incoming' patches directory would be empty and clk-next would only be a fast-forward merge of clk-3.x by the time Linus' merge window opens. So in that regard I am following the guidelines to treat my pull request to linux-next as the same thing I would send to Linus.

Finally, I have never meant to throw bad patches at linux-next, so perhaps I shouldn't have used the term "breakage" in my above mail. I only meant that from the perspective of downstream developers pulling a rebased clk-next branch. I do not intend to put patches into linux-next which are not unit tested first.

So please let me know if I still have the concept wrong and I'll change things up. Otherwise my clk-next fulfils all of the guidelines you've mentioned below for inclusion into linux-next.

Thanks much,
Mike

Hi Mike,

OK, that all seems to be fine. I would make one suggestion: that you create the clk-next branch like this:

git checkout clk-next
git reset --hard clk-3.x
git merge clk-fixes
git am patches/clk/next/incoming/*.patch

or maybe just merge clk-fixes directly into clk-3.x when necessary or
from time to time and base clk-next just in clk-3.x.
--
Cheers,
Stephen Rothwell sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120628/c338de11/attachment.sig>

Using clk-3.x as a base for clk-next sounds fine to me. I'll use the approach you outlined above.

Thanks much,
Mike

So I don't see this being pulled into -next, is it just a slip, I though the structure of the branch was agreed upon and all?

(I have patches in there, that's why I'm hammering.)

Yours,
Linus Walleij

Hi Linus,

I am waiting for Mike to let me know its all ready to add ...

Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120703/e1f5dade/attachment.sig>

Oops. I thought everything was sorted after our last email. I've gone ahead and updated clk-next based on our discussions, so please do pull it in.

Thanks much,
Mike

Hi Mike,

This will be added form today.

Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgment of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window.

You will need to ensure that the patches/commits in your tree/series have been:
* submitted under GPL v2 (or later) and include the Contributor's Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary.

Cheers,
Stephen Rothwell 
sfr at canb.auug.org.au

Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees.  You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next.  These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc.  The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc.  If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120703/a657ab5b/attachment.sig>