[oe] Reconsidering the work flow and how the SCM system fits in

[Paul Sokolovsky]

Hello,

On Tue, 11 Mar 2008 08:07:10 +0100
Holger Freyther <zecke at selfish.org> wrote:

> Hey,
> 
> 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.
> 
> 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.

These latest 2 sound very nice in "SCM for dummies" book, but work in
real life only if many people are *forced* to do that. Works well in
commercial shops ;-). I doubt that's scalable for an average OpenSource
project.

> 	- Stable distributions and vendors get their own branch, they
> can merge, cherry-pick what ever they want.
> 
> 
> The issue:
> 	- mtn can not merge. Forcing me to manually delete files in
> one copy to do a merge is not acceptable.
> 	- mtn has not the concept of short-lived branches (e.g.
> deleting their existence once done), mtn suspend does not work as
> witnessed by our automerger.
> 	- mtn pluck is not making me happy
> 	- I lack a GUI to easily browse the repository
> 	- I can not clean up changes before I push them!

I kinda agree with these.

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

I would sound my personal contributing developer's opinion here by
saying that any migration talks may happen only if complete changes
migration is proposed. Losing history is unacceptable. Not being able
to trace changelog beyond bitkeeper migration point is pretty
disabling already.

> 
> My criteria:
> 	- Should have branches, easy merging, easy merging of merges
> 	- Branches and merging should be cheap
> 	- Make it easy to put the OE tree into another SCM and still
> be able to merge (git-svn and such)
> 	- A good graphical tool to browse the repository
> 	- A good and maintained web frontend
> 	- A good set of builtin tools (e.g. like git-add -i and
> git-rebase -i)
> 
> I think the two options are hg and git, I tend to favor git due the
> size of its community. 

git suxx, hg rules ;-D. Well, I yet have to see an SCM which does
merges and cherry-picking properly (recording all merge events,
allowing to merge and recombine in arbitrary order, etc.).

And I have no idea how hg supports rebase and stuff, or used it in git
either. I'm sure they suck at that ;-). Also, good political move for
making choices for diversified community which cannot reach concord is
to select worst choice, not the best - this way noone will feel made
wrong in favor of others ;-). That worked well for me with mtn - I
currently feel much better about it than when I started, and glad that
I was made acquainted with yet another SCM. 

Well, per all abobe reasons, I vote for git too. 

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

Push it, push it! But with complete history, of course.

> 
> 
> comments? agreement?
> 
> 	z.
> 
> 
> PS: It is not the speed of mtn, it is the lack of development in
> areas like branches, merging, rebasing, we need to use these in OE!


-- 
Best regards,
 Paul                          mailto:pmiscml at gmail.com