VCS Workflow and continuous integration

Assigning myself. We also need to work out the continuous integration.

Reporting progress: I have set up a temporary bzr hosting at http://uc.damz.org/branches/. I'm studying how to properly set up a bzr-to-cvs bridge.

Damien has done a lot of work to get us setup on Launchpad. Many thanks to him! As he's walked me through what Launchpad has to offer, it seems like a perfect fit for rapid, collaborative development. Here's the gist of it:

1. Launchpad will host the main development branch and also associate with it any forks that Launchpad users create from it.
2. So, anyone collaborating on core development, will simply have to fork it to their system and do development locally.
3. Developers can merge their branches as they work on features together (or of course develop on their own as necessary).
4. When the developer(s) think the code is ready to be committed to the main branch, they create a merge request on Launchpad. This gives us a place for anyone involved in the project to review the changes with a tidy revision log and formatted diff.
5. If the core maintainer signs off on it, the branch in question is merged in and committed to core. Commits to the main branch would be auto-synced to Drupal CVS.

That addresses how Launchpad would be used. As for other questions, I believe we've discussed the following points in the past:

• All this would be well documented and ideally screencasted so anyone who wants to be involved can be. Once we've nailed down all the project / group names, we'll include all the necessary links and information for people to contribute.
• This method of development wouldn't exclude developers from working against CVS head on d.o and posting patches to the issue queue. The core maintainer could still commit those directly, or anyone working through Launchpad could test it on their branch and request to merge it to the main branch.
• Launchpad seems ideal for community familiarity, Bazaar support, and possibly some other workflow related tools. For example, we can make "blueprints" to releases there that summarize / link to the design documents on d7uc.org.

So, am I missing anything conceptually in the Launchpad workflow, and are there other points we've discussed that are pertinent here?

As I work with Bazaar for the first time on this I'm updating info on http://d7uc.org/node/21

Seems like you guys have opted for github as per
http://www.drupalcommerce.org/node/106

and the page http://www.drupalcommerce.org/development/workflow needs to reflect these changes

Alrighty, I updated that page and tweaked the URL for node/106 to http://www.drupalcommerce.org/development/github. I'm sure there are more questions that could be answered, but I'm wondering if this is sufficient for now?

One little thing that i am not sure about is what repo should one fork ? the one on drupalcommerce of rszrama ? i'd say drupalcommerce but your fork seems to be the most "updated" ? again i'm new to github so any tips are welcome

Ahh, good point and definitely deserves clarification. I'm not sure how necessary this is, but I forked the main repo and then merged in Damien's fork to preserve the association of my fork on GitHub with the main repository. I'd recommend you do the same, but in the end all that matters is that the code can get back to the main repo somehow. : P

Will try to follow-up with this in the docs on DC.org.

Updated the docs a little bit to bold the statement about forking the main repository. I'm going to consider this fixed for now, as the initial task is done and we can always update the docs in the future.