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,
On Mon, 25 Jun 2012 18:55:51 -0700 Mike Turquette <[email protected]> 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 [email protected]
On 20120626-13:25, Stephen Rothwell wrote:
> Hi Mike,
>
> On Mon, 25 Jun 2012 18:55:51 -0700 Mike Turquette <[email protected]> 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 [email protected]
Hi Mike,
On Tue, 26 Jun 2012 16:05:03 -0700 Mike Turquette <[email protected]> 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 [email protected]
On 20120628-00:29, Stephen Rothwell wrote:
> Hi Mike,
>
> On Tue, 26 Jun 2012 16:05:03 -0700 Mike Turquette <[email protected]> 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 [email protected]
On Tue, Jun 26, 2012 at 3:55 AM, Mike Turquette <[email protected]> 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