linux-next: adding the common clk tree

linux-next: adding the common clk tree

[Mike Turquette]

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

linux-next: adding the common clk tree

[Stephen Rothwell]

Hi Mike,

On Mon, 25 Jun 2012 18:55:51 -0700 Mike Turquette <mturquette@ti.com> wrote:
>
> 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.

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>

linux-next: adding the common clk tree

[Mike Turquette]

On 20120626-13:25, Stephen Rothwell wrote:
> Hi Mike,
> 
> On Mon, 25 Jun 2012 18:55:51 -0700 Mike Turquette <mturquette@ti.com> wrote:
> >
> > 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.
> 
> 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)?
> 

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

> 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

linux-next: adding the common clk tree

[Stephen Rothwell]

Hi Mike,

On Tue, 26 Jun 2012 16:05:03 -0700 Mike Turquette <mturquette@ti.com> wrote:
>
> 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.

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>

linux-next: adding the common clk tree

[Mike Turquette]

On 20120628-00:29, Stephen Rothwell wrote:
> Hi Mike,
> 
> On Tue, 26 Jun 2012 16:05:03 -0700 Mike Turquette <mturquette@ti.com> wrote:
> >
> > 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.
> 
> 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.

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

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

linux-next: adding the common clk tree

[Linus Walleij]

On Tue, Jun 26, 2012 at 3:55 AM, Mike Turquette <mturquette@ti.com> wrote:

> 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

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

linux-next: adding the common clk tree

[Stephen Rothwell]

Hi Linus,

On Sat, 30 Jun 2012 21:47:35 +0200 Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Tue, Jun 26, 2012 at 3:55 AM, Mike Turquette <mturquette@ti.com> wrote:
> 
> > 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
> 
> 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 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>

linux-next: adding the common clk tree

[Turquette, Mike]

On Mon, Jul 2, 2012 at 4:33 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Linus,
>
> On Sat, 30 Jun 2012 21:47:35 +0200 Linus Walleij <linus.walleij@linaro.org> wrote:
>>
>> On Tue, Jun 26, 2012 at 3:55 AM, Mike Turquette <mturquette@ti.com> wrote:
>>
>> > 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
>>
>> 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 am waiting for Mike to let me know its all ready to add ...
>

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

> --
> Cheers,
> Stephen Rothwell ? ? ? ? ? ? ? ? ? ?sfr at canb.auug.org.au

linux-next: adding the common clk tree

[Stephen Rothwell]

Hi Mike,

On Mon, 25 Jun 2012 18:55:51 -0700 Mike Turquette <mturquette@ti.com> wrote:
>
> 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

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>