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