[haiku-development] Moving away from Subversion, pt. 2
- From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 30 Jun 2010 20:06:35 +0200
Hi there,
it seems like we've brought the first part of the tool discussion behind
us, fine ;-)
I'd like to pick up (and amplify) what Niels has said: we need to pick a
preferred workflow first (or a set of workflows that we want to support).
Only after we've done that, we can look at the tools again and decide which
fits best.
The bazaar website has a nice summary of several workflows here:
http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/bazaar_workflows.html
I think it is safe to say that we'd like to move away from the
'Centralized' workflow which we've been using all along, but it's not
really clear just which of the other workflows would fit project haiku best.
- 'Centralized with local commits' is definitely an improvement over how we
work now, but it would basically just help committers by allowing them to
work offline. All branches would (by workflow design) still live in the
central repo.
- in the 'Decentralized with Shared Mainline' workflow, committers may work
on branches in the central repo or in their own repository/ies. Peer-review
and -programming would require that developer-specific repositories are
accessible by others, otherwise the development isn't visible until the
developer pushes the commits into the central repository.
- the 'Decentralized with human gatekeeper' workflow is a tough one to
implement if there aren't enough devs motivated to be gatekeepers. Judging
by the amount of peer-review we get done, I suppose this might be difficult
for us.
- the 'Decentralized with automatic gatekeeper' workflow is probably less
problematic to implement, but the result would be less valuable than with a
human gatekeeper (i.e. most probably it'd be that haiku still builds with
the incoming changes applied).
Obviously, none of these workflows are fixed, they can (and probably need
to) be adjusted to form our own workflow.
Here are a couple of questions that hopefully can help getting an idea:
- where should branches live, in the central repository, in local
repositories, or in both (depending on how long-lived they are meant to be)?
- if there are branches in the central repository, should they be available
as individual repositories (such that they can be pulled individually), or
do we pull the whole thing always?
- do we try to avoid that using a DVCS moves some part of the development
into the dark (into local repositories) or do we trust that devs will find
the way to publish/share their repos that fits them best?
- as a counter measure to decreased visibility, is it a good idea to
support shared, dev-specific repositories on the server, with e.g.
potential integration into haiku-commits?
- how do we try to make it easier for external contributors
(non-committers) to get their patches reviewed and applied - is the
technical improvement of using a DVCS enough or do we need something better?
- is Trac a sacred cow or are we prepared to look for something else if the
DVCS of our choice doesn't work well with Trac?
- during the import of subversion's history into the DVCS, would it be
acceptable if some part of the history of renamed and/or copied files gets
lost? Would keeping a mirror of the subversion repo be enough to compensate?
Well, that's it for now, eagerly awaiting your input ...
cheers,
Oliver
Other related posts:
