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

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Holger Freyther schreef:
| 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.
| 	- 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 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.
|
| 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. 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.

If we switch, my vote would be for hg.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH1lPIMkyGM64RGpERAutoAJ44F/prApfsKU+QcHzCV5fuGunv/wCgmeg5
HVUPl5aPPXoA62PzychJLJA=
=jz3J
-----END PGP SIGNATURE-----