Re: Reconsidering the work flow and how the SCM system fits in

[Florian Boor <florian.boor@kernelconcepts.de>]

Hello,

Holger Freyther schrieb:
> I'm anything but happy with the way we work with our repository. We have a 
> dreambox branch that is not mergable due issues with our SCM system, the 
> OpenMoko guys have to go back to diffing and applying the diff and merging by 
> hand, we just commit fundamental changes like sysroot, packaged-staging, RFCs 
> in one go and then do weeks of fixing. And I can continue with this list.

agreed, looking at other projects it becomes clear that we could do much better.

> What: I think we should use more branches
> 	- As many shortlived and medium lived branches as developers want
> 	- Shared branches for stuff like packaged staging, RFCs, sysroot. Were you
> 	  start the development, add features, other people will compile their stuff, 
> 	  other compile and then you rebase and merge!
> 	- Basicly you develop a feature in a branch until it is ready and not 
> 	  impacting other things, then you rebase/cleanup, propose it for inclusion 
> 	  and wait for feedback, then merge.
> 	- Stable distributions and vendors get their own branch, they can merge, 
> 	  cherry-pick what ever they want.

This implies a similar workflow like for the Linux kernel development. With
working tools a good idea. The only disadvantage I see is that a major share of
the developers (including myself) might not be used to this yet. But I would be
fine with that.

> The issue:
> 	- mtn can not merge. Forcing me to manually delete files in one copy to do a 
> 	  merge is not acceptable.

That's the major drawback of mtn - even CVS is better resolving conflicts.
Another major issue is the missing support for atomic operations. If an update
fails it happens that you end up in an undefined state where it is hard or even
impossible to recover from.

> I want that we use more branches for development, apply review on them, 
> land/merge/push these branches after review, pull peoples changes from other 
> hosts, work on perfetch patch series before landing patches. I believe we 
> need to deploy this kind of development in OE again and as mtn is the 
> obstacle to this kind of development I propose to switch to another SCM 
> system that allows us to develop OpenEmbedded the way it should be developed.

It would reduce the effort for maintaining a kind of 'testing' branch (in the
sense of Debian testing) where we put in stuff that is quite up to date but
basically tested.

> My criteria:
> 	- Should have branches, easy merging, easy merging of merges
> 	- Branches and merging should be cheap
Yes, very important.

> 	- Make it easy to put the OE tree into another SCM and still be able
> 	  to merge (git-svn and such)
that's another good point - OE is used as a tool for other projects who might
have decided for a different SCM before (e.g. OpenMoko and Poky). This would
make it much easier to integrate their work with OE and merge back changes.
For OE I would see this as a one of the key features the SCM must have.

> I think the two options are hg and git, I tend to favor git due the size of 
> its community. I want to switch OE to one of these systems by the end of this 
> month and start using more branches and creating perfect patch series again.

I do not think there are more candidates, but even deciding for one of these is
hard. :-} Do we have a good comparison between these somewhere?

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de

1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76