[ANN] Introducing new "test" branch in powerpc.git tree

[ANN] Introducing new "test" branch in powerpc.git tree

[Benjamin Herrenschmidt]

Hoy !

So I've been annoyed for some time by the way we do our preparation for
the next merge window. The "next" branch is defined as not being rebased
ever (well, as much as possible), which makes it impossible to just
stash things early in there and rebase if needed, which is a useful
exercise in the weeks leading to the merge window to be able to test
patches, fix them, etc... while keeping a good idea of what's planned to
go in.

Thus I've created a "test" branch. I'll push it out later today with
various things pending. For pulls from sub-maintainers, I'll probably
merge into "next" quickly (ie. a day or two after hitting "test" just
enough time to find gross problems). That will allow me to be more
pro-active also at pulling things off the mailing list and sticking them
there even if some cosmetic changes have been requested to the patch as
I will have no issue rebasing it when the new patch comes in.

Now, one important rule is: test will be reset at the beginning of every
merge window. I will not let it degenerate into the old linuxppc-dev bk
tree that drifted for years and had things that never got merged.

I'm also not sure whether sub-maintainers should do the same thing with
a "test" branch of their own. I certainly don't mind if they rebase
their "next" branches so I'm happy for them to play the same game
directly into their 'next' branch as long as the day they ask me to pull
it into the real 'next', they are reasonably confident that the stuff in
there is stable.

For any complaint, see my secretary in the Oort cloud.

Cheers,
Ben.

Re: [ANN] Introducing new "test" branch in powerpc.git tree

[Grant Likely]

On Wed, Feb 4, 2009 at 9:01 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> [...]
> Now, one important rule is: test will be reset at the beginning of every
> merge window. I will not let it degenerate into the old linuxppc-dev bk
> tree that drifted for years and had things that never got merged.
>
> I'm also not sure whether sub-maintainers should do the same thing with
> a "test" branch of their own. I certainly don't mind if they rebase
> their "next" branches so I'm happy for them to play the same game
> directly into their 'next' branch as long as the day they ask me to pull
> it into the real 'next', they are reasonably confident that the stuff in
> there is stable.

I'm cool with this.  I certainly maintain a branch which is frequently
rebased and that is exactly where I stash stuff as I try to decide
what to do with it.  The only difference is that mine isn't usually
public.  If people want to see it, then I push it out, but otherwise I
just wait until I've got a real pull request.

In fact, in this cycle I did push out to my -next and then had to redo
it before I sent my pull request because one of the middle commits had
an oops (but, nobody bases their patches on my -next tree, so it
doesn't have the same repercussions).

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [ANN] Introducing new "test" branch in powerpc.git tree

[Kumar Gala]

On Feb 4, 2009, at 10:01 PM, Benjamin Herrenschmidt wrote:

> Hoy !
>
> So I've been annoyed for some time by the way we do our preparation  
> for
> the next merge window. The "next" branch is defined as not being  
> rebased
> ever (well, as much as possible), which makes it impossible to just
> stash things early in there and rebase if needed, which is a useful
> exercise in the weeks leading to the merge window to be able to test
> patches, fix them, etc... while keeping a good idea of what's  
> planned to
> go in.
>
> Thus I've created a "test" branch. I'll push it out later today with
> various things pending. For pulls from sub-maintainers, I'll probably
> merge into "next" quickly (ie. a day or two after hitting "test" just
> enough time to find gross problems). That will allow me to be more
> pro-active also at pulling things off the mailing list and sticking  
> them
> there even if some cosmetic changes have been requested to the patch  
> as
> I will have no issue rebasing it when the new patch comes in.
>
> Now, one important rule is: test will be reset at the beginning of  
> every
> merge window. I will not let it degenerate into the old linuxppc-dev  
> bk
> tree that drifted for years and had things that never got merged.
>
> I'm also not sure whether sub-maintainers should do the same thing  
> with
> a "test" branch of their own. I certainly don't mind if they rebase
> their "next" branches so I'm happy for them to play the same game
> directly into their 'next' branch as long as the day they ask me to  
> pull
> it into the real 'next', they are reasonably confident that the  
> stuff in
> there is stable.
>
> For any complaint, see my secretary in the Oort cloud.

Are you going to ask "test" get pulled into Stephen's -next tree?

- k

Re: [ANN] Introducing new "test" branch in powerpc.git tree

[Benjamin Herrenschmidt]

On Wed, 2009-02-04 at 23:53 -0600, Kumar Gala wrote:
> 
> Are you going to ask "test" get pulled into Stephen's -next tree?

No, I don't intend to let things stage long enough in "test" for that to
matter and I asked Stephen, he isn't hot about it. Hopefully the max
lifetime for something in "test" should be around a week.

It's really a way for me to advertise what I want to push out and still
have a last minute chance to catch big mistakes.

Cheers,
Ben.

Re: [ANN] Introducing new "test" branch in powerpc.git tree

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

On Wed, Feb 04, 2009 at 09:20:04PM -0700, Grant Likely wrote:

> what to do with it.  The only difference is that mine isn't usually
> public.  If people want to see it, then I push it out, but otherwise I
> just wait until I've got a real pull request.

I'd like to see that tree public, so I can check anytime if you already
have picked up a patch or if it has been overlooked...

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [ANN] Introducing new "test" branch in powerpc.git tree

[Josh Boyer]

On Thu, Feb 05, 2009 at 03:01:33PM +1100, Benjamin Herrenschmidt wrote:
>Hoy !
>
>So I've been annoyed for some time by the way we do our preparation for
>the next merge window. The "next" branch is defined as not being rebased
>ever (well, as much as possible), which makes it impossible to just
>stash things early in there and rebase if needed, which is a useful
>exercise in the weeks leading to the merge window to be able to test
>patches, fix them, etc... while keeping a good idea of what's planned to
>go in.
>
>Thus I've created a "test" branch. I'll push it out later today with
>various things pending. For pulls from sub-maintainers, I'll probably
>merge into "next" quickly (ie. a day or two after hitting "test" just
>enough time to find gross problems). That will allow me to be more
>pro-active also at pulling things off the mailing list and sticking them
>there even if some cosmetic changes have been requested to the patch as
>I will have no issue rebasing it when the new patch comes in.

I like this.  So we have:

test -> testing stuff
next -> stuff that's been tested and is queued up for the next release
merge -> fixes for the currently being worked on release

Which begs the question of what master is for.  So far, it's just been
a mirror of next from what I can tell.  Maybe it should just track
Linus' tree?

josh

Re: [ANN] Introducing new "test" branch in powerpc.git tree

[Grant Likely]

On Thu, Feb 5, 2009 at 2:45 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> On Wed, Feb 04, 2009 at 09:20:04PM -0700, Grant Likely wrote:
>
>> what to do with it.  The only difference is that mine isn't usually
>> public.  If people want to see it, then I push it out, but otherwise I
>> just wait until I've got a real pull request.
>
> I'd like to see that tree public, so I can check anytime if you already
> have picked up a patch or if it has been overlooked...

Sure, I can push it out.  It will be a little haphazard though.  I
maintain it using stacked git, so not all the things that I have in
the stack are actually applied at any given time, but I will try to
keep it up to date as I pick things up.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [ANN] Introducing new "test" branch in powerpc.git tree

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]


> Sure, I can push it out.  It will be a little haphazard though.  I
> maintain it using stacked git, so not all the things that I have in
> the stack are actually applied at any given time, but I will try to
> keep it up to date as I pick things up.

Cool, thanks, this will do!

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [ANN] Introducing new "test" branch in powerpc.git tree

[Benjamin Herrenschmidt]

> Which begs the question of what master is for.  So far, it's just been
> a mirror of next from what I can tell.  Maybe it should just track
> Linus' tree?

I've been wondering myself what to do with it ... I may just leave it to
track linus indeed. Or maybe just delete it.

Ben.

Re: [ANN] Introducing new "test" branch in powerpc.git tree

[Josh Boyer]

On Fri, Feb 06, 2009 at 07:56:22AM +1100, Benjamin Herrenschmidt wrote:
>
>> Which begs the question of what master is for.  So far, it's just been
>> a mirror of next from what I can tell.  Maybe it should just track
>> Linus' tree?
>
>I've been wondering myself what to do with it ... I may just leave it to
>track linus indeed. Or maybe just delete it.

I don't think you can delete it without hosing people who try to clone it.

josh

Re: [ANN] Introducing new "test" branch in powerpc.git tree

[Michel Dänzer]

On Thu, 2009-02-05 at 15:58 -0500, Josh Boyer wrote:
> On Fri, Feb 06, 2009 at 07:56:22AM +1100, Benjamin Herrenschmidt wrote:
> >
> >> Which begs the question of what master is for.  So far, it's just been
> >> a mirror of next from what I can tell.  Maybe it should just track
> >> Linus' tree?
> >
> >I've been wondering myself what to do with it ... I may just leave it to
> >track linus indeed. Or maybe just delete it.
>=20
> I don't think you can delete it without hosing people who try to clone it=
.

The branch to check out by git clone can be overridden via a special
file in the .git directory in the shared repository. Unfortunately
though, I don't remember what it's called...


--=20
Earthling Michel D=C3=A4nzer           |                http://www.vmware.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

Re: [ANN] Introducing new "test" branch in powerpc.git tree

[Michel Dänzer]

On Fri, 2009-02-06 at 18:42 +0100, Michel D=C3=A4nzer wrote:
> On Thu, 2009-02-05 at 15:58 -0500, Josh Boyer wrote:
> > On Fri, Feb 06, 2009 at 07:56:22AM +1100, Benjamin Herrenschmidt wrote:
> > >
> > >> Which begs the question of what master is for.  So far, it's just be=
en
> > >> a mirror of next from what I can tell.  Maybe it should just track
> > >> Linus' tree?
> > >
> > >I've been wondering myself what to do with it ... I may just leave it =
to
> > >track linus indeed. Or maybe just delete it.
> >=20
> > I don't think you can delete it without hosing people who try to clone =
it.
>=20
> The branch to check out by git clone can be overridden via a special
> file in the .git directory in the shared repository. Unfortunately
> though, I don't remember what it's called...

According to Julien Cristau of the Debian X Strike Force (none of the
Git repos of which have a master branch), it should be .git/HEAD. Some
experiments of mine seem to confirm this.


--=20
Earthling Michel D=C3=A4nzer           |                http://www.vmware.c=
om
Libre software enthusiast         |          Debian, X and DRI developer