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

2009-02-08 Thread Michel Dänzer
On Fri, 2009-02-06 at 18:42 +0100, Michel Dänzer 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 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.
> 
> 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.


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

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

2009-02-06 Thread 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.
> 
> 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...


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

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

2009-02-05 Thread 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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


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

2009-02-05 Thread 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.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


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

2009-02-05 Thread Wolfram Sang

> 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/  |


signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

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

2009-02-05 Thread Grant Likely
On Thu, Feb 5, 2009 at 2:45 AM, Wolfram Sang  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.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


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

2009-02-05 Thread 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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


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

2009-02-05 Thread Wolfram Sang
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/  |


signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

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

2009-02-04 Thread 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.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


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

2009-02-04 Thread 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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


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

2009-02-04 Thread Grant Likely
On Wed, Feb 4, 2009 at 9:01 PM, Benjamin Herrenschmidt
 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.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


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

2009-02-04 Thread 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.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev