Re: Kernel SCM saga..

Re: Kernel SCM saga..

[Wolfgang Denk]

Hi,

are there any plans yet how to continue PPC  kernel  development  now
that Linus (and probably others, too) stopped using BitKeeper?

See http://www.lib.uaa.alaska.edu/linux-kernel/archive/2005-Week-14/0826.html

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Far back in the mists of ancient time, in the great and glorious days
of the former Galactic Empire, life was wild, rich  and  largely  tax
free.         - Douglas Adams, _The Hitchhiker's Guide to the Galaxy_

Re: Kernel SCM saga..

[Tom Rini]

On Thu, Apr 07, 2005 at 12:37:46AM +0200, Wolfgang Denk wrote:

> Hi,
> 
> are there any plans yet how to continue PPC  kernel  development  now
> that Linus (and probably others, too) stopped using BitKeeper?
> 
> See http://www.lib.uaa.alaska.edu/linux-kernel/archive/2005-Week-14/0826.html

Larely unchanged.  The linuxppc-2.5 tree hasn't been active for a while,
so "official" trees shouldn't be a problem.  I would hope/imagine that
whatever is picked up next will allow the sub-projects that've had
multiple colaborators (such as mpc52xx or marvell support) to work in
some fashion.  For single-user stuff, I can't recommend quilt
(http://savannah.nongnu.org/projects/quilt) enough.

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: Kernel SCM saga..

[Eugene Surovegin]

On Thu, Apr 07, 2005 at 12:37:46AM +0200, Wolfgang Denk wrote:
> are there any plans yet how to continue PPC  kernel  development  now
> that Linus (and probably others, too) stopped using BitKeeper?

Well, most of the recent 2.6 PPC kernel development was based on 
sending _patches_ to akpm, I don't see how Linus' decision to stop 
using BK will significantly affect this.

Also, BK trees don't go anywhere right now, so I guess we can still 
use BK to get/maintain the latest official sources for patch 
generation. I'm pretty sure Linus and other maintainers will come up 
with replacement. Probably it won't be as convenient as BK at first, 
but I hope this will be fixed eventually - there are couple of open 
source revision control systems out there which look promising.

So, I wouldn't overly dramatize current situation.

--
Eugene

Re: Kernel SCM saga..

[Dan Malek]

On Apr 6, 2005, at 6:37 PM, Wolfgang Denk wrote:

> are there any plans yet how to continue PPC  kernel  development  now
> that Linus (and probably others, too) stopped using BitKeeper?

For all practical purposes, we have stopped using it as intended long
ago.   When we first started, those of us responsible for maintaining 
part
of the sources simply continuously pushed updates.  Very efficient, 
everyone
saw what was up to date.  Since 2.4, we have all been passing patches
around,  pushing things into BK didn't seem to matter, and usually
were ignored or lost.  People responsible for certain areas of 
maintenance
are now just bypassed with sometimes bad patches just given to Andrew
directly.  We may as well go back to using CVS and passing patches
around, since it easier to do that than the way we have been using BK.

Thanks.

	-- Dan

Re: Kernel SCM saga..

[Benjamin Herrenschmidt]

On Wed, 2005-04-06 at 19:33 -0400, Dan Malek wrote:
> On Apr 6, 2005, at 6:37 PM, Wolfgang Denk wrote:
> 
> > are there any plans yet how to continue PPC  kernel  development  now
> > that Linus (and probably others, too) stopped using BitKeeper?
> 
> For all practical purposes, we have stopped using it as intended long
> ago.   When we first started, those of us responsible for maintaining 
> part
> of the sources simply continuously pushed updates.  Very efficient, 
> everyone
> saw what was up to date.  Since 2.4, we have all been passing patches
> around,  pushing things into BK didn't seem to matter, and usually
> were ignored or lost.  People responsible for certain areas of 
> maintenance
> are now just bypassed with sometimes bad patches just given to Andrew
> directly.  We may as well go back to using CVS and passing patches
> around, since it easier to do that than the way we have been using BK.

The problem is that we used to have our "own" tree which ended up beeing
a grab bag for all the crap on earth and would drift from upstream in
unmanageable ways.

We are now working much more directly with upstream, and it's not about
random people sending random patches to akpm, for most arch patches,
andrew is actually asking us (or rather paulus) whether to accept or not
the patch. It does sometimes slip through but that's minimal.

If you feel that your stuff isn't properly going upstream in time, then
maybe that is because you aren't sending the patch to the right person
or putting it in the right place ?

All patches posted to linuxppc-dev and linuxppc64-dev are tracked by an
automatic system. They may take some time to go upstream, but they are
never lost.

Ben.