Interesting post from one project recently moved to bzr.
Bryce
----- Forwarded message from Loïc Minier <loic.minier@...1798...> -----
Date: Tue, 01 Apr 2008 17:27:05 +0200 From: Florian Boucault <florian@...693...> To: elisa <elisa@...1936...> Subject: [Elisa] Elisa organisation changes X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_50 autolearn=disabled version=3.1.3
Hello Eliseros,
After careful thinking, the Elisa team has decided to move over to Bazaar for version control and to Launchpad for bug tracking and release management.
** Why the move? **
The Elisa project is all about people making their own customised media center that fits their own particular needs. This is the rationale behind its fully pluggable architecture. In order to allow a similar flexibility for developers, it made complete sense to use a distributed version control system (DVCS). The choice between the myriad of existing DVCSes was driven by a simplicity of use enabling easy contribution and flexibility to adapt to any possible workflow we may need in the future. For all these reasons Elisa's source code, which was previously versioned using Subversion, is from now on stored in Bazaar branches. Bazaar is well documented and has nice tutorials help people get started such as this one:
http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html
Obviously a full move to a decentralised working style meant that a good tool was needed to keep track of what is going on in the branches, bugs wise and also features wise. After some experiments with various tools that could have done the job, Launchpad proved to cover the use cases well and enable the kind of collaboration we all want to encourage.
** Teams and their purpose **
We are going to setup 2 launchpad teams. The first team, called elisa-developers, will be opened to all the developers that have read and signed the Fluendo copyright assignment document. Everyone will be able to branch bazaar branches registered by the elisa-developers team, but only the members will have write access to them. The second team, called elisa-contributors, will be open to everyone. Every member will have write access to the branches under the team. This team will make it easy for groups of developers to work together on their branches whenever and however they want to.
** Contribution processes **
Code ----
The first thing needed to start hacking on Elisa is a branch of an existing branch. The main development branch is at:
http://bazaar.launchpad.net/~elisa-developers/elisa/main
We never push directly to the main branch as we want all the changes to be reviewed first. When a developer wants some code to be committed, he sends a merge request to the elisa-commits@...1936... mailing list by using the bzr send command, which is documented here:
http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#sending-changes
On the mailing list the changes are reviewed by one or more developers and, once they have been approved, they are merged into the main branch.
The merging procedure varies depending on which bundle the changed code belongs. Changes to core, -base, -good, and -ugly have to be reviewed by at least two developers, changes to -bad by at least one developer. The last reviewer merges the changes back into the branch.
We will setup a Bundle Buggy instance to track the merge requests and the reviews. The voting system used by Bundle Buggy is defined here:
http://bundlebuggy.aaronbentley.com/help
Bug reports -----------
Bug reports are stored in Launchpad which allows a per branch fine tracking of bugs. There is nothing really new here apart from the ability to have cross projects bug which will prove fairly useful in Elisa's case since it depends on many other libraries (eg. Pigment, GStreamer, etc.).
Specifications --------------
Task specifications for new features will be centralised in one place in the upcoming Elisa's wiki and tracked in Launchpad blueprints allowing a quick and easy overview of all the current work being done and the various branches related to them.
A quick task definition is written in Launchpad blueprints itself whereas more detailed information will be stored in Elisa's wiki and will contain: summary, rationale, use cases, implementation plan and whatever is necessary to communicate around the task.
That's it for now. Thank you for reading so far. Hopefully all these changes and decisions will help make Elisa go forward by allowing everyone to collaborate as painlessly as possible. If there are any questions please do not hesitate to ask.
The Elisa team
** Bundles policies **
Elisa's plugins are sorted into bundles depending on various criteria such as quality, dependencies, licensing, etc. Currently 4 bundles exist: base, good, bad and ugly. The policy is heavily based on GStreamer's (http://gstreamer.freedesktop.org/documentation/splitup.html)
Base ----
- Must be of good code quality and fully functional - Must be well-tested (unittests, good code coverage, etc.) - Must comply with Elisa dual license model or be under MIT or a BSD license - Cannot depend on external libraries that Elisa core does not depend on
Good ----
- Must be of good code quality and fully functional - Must be well-tested (unittests, good code coverage, etc.) - Must comply with Elisa dual license model or be under MIT or a BSD license
Bad ---
- Bad quality code (coding style not respected, etc.) - Not very well tested, not mature - Must comply with Elisa dual license model or be under MIT or a BSD license - Might have potential legal issues
Ugly ----
- Must be of good code quality and fully functional - Must be well-tested (unittests, good code coverage, etc.) - Not complying with Elisa dual license model (eg. can be GPL only) - Might have potential legal issues