[bt-devel] The future of development and DVCS

[Eeli Kaikkonen]

On Sat, 5 Dec 2009, Martin Gruner wrote:

> Eeli,
>
> we have talked about this topic already.
>
> My opinion is:
> - SF SVN works well for us (except that it is slow, but I expect this to
> change at some point in future)
> - all developers must be able to work easily with our VCS. Personally I'd
> prefer something with good Eclipse integration.
> - it must be obvious that a change will bring benefits and does not disturb our
> development process.
> - we need to have a thorough testing phase where we work together on a "dummy"
> repository to see how things work. Only if we then feel it is worth it we
> should switch.
>
> If these criteria are met, I'm ready for a change. =) We might want to start
> with setting up a dummy git repository and see how we can get along with it
> (we shouldn't test several in parallel). A collection of _simple_ videos like
> the ones on github might be nice as a starter for dummies like me.
> For now, development should stay in SVN.


Development will stay in svn until we all agree otherwise, there's no
fear about that.

I also agree, like I did at the first discussion round, that we have to
test first. No I started discussion again because we have more
developers and I have gained a little bit more knowledge about these
things.

It might be possible to use a dvcs for experimental branching but keep
the main development in svn. The workflow would be like this:
* official trunk in svn
* a dvcs with no official trunk, only experimental branches
* anyone can create a branch in dvcs
* features (or fixes as well) are developed in public branches instead
  of in secret in private machines, as they do now
* anyone can follow feature developent of each developer, unlike now
* when a feature is ready, it's announced and anyone can check it
* if there are no complaints, the developer can commit it to the svn
  repository (or another developer can commit it)

Eventually the code quality would be better than now because this
encourages peer review, there would be less clashes between different
developers' changes, there would be no need to revert changes from svn,
everyone would know what others are doing, outsiders (without svn commit
rights) could create branches instead of sending patches.

This isn't of course automatic. The greatest problem are people. If we
want better quality, we need more peer review. That doesn't happen
unless we do it. Another possibility is a human gatekeeper (or several)
who is the only one to make commits after reviewing changes, but I think
we don't want that.

  Yours,
	Eeli Kaikkonen (Mr.), Oulu, Finland
	e-mail: eekaikko at mailx.studentx.oulux.fix (with no x)