Alpha to Beta to GA Code Release strategy

[Murdock]

I'm attempting to get my head around the development and release process. I'm going to throw out a few things and would like someone to comment:

1. Features and issues:
  Features are requested via the TRAC system and validity of features are decided upon by a PRB (priority review board) and are assigned (or dismissed) based on resource availability and whether the change is appropriate based on current release or future (roadmap) releae.

2. Release Strategy:
  Releases (builds) are done on each yearly x.10 release of Kubuntu and GA dates are based upon developer availability and number of issues/features included in the TRAC system.

3. Updates to code:
  If someone wants to correct an issue or correct a feature, this person would need to be plugged into either the PRB or community leader in order to be assigned via the TRAC system and have access to the latest build to update.

4. Testing cycle
  Upon completion of an update, information regarding the update is posted on the wiki to track the changes and a new alpha/beta release is made.


Comments are welcome!

Thank you,
Ryan

[tschak909]

I have no problem with this. Hari? Possy?

-Thom

[Alaith]

3. Updates to code:
  If someone wants to correct an issue or correct a feature, this person would need to be plugged into either the PRB or community leader in order to be assigned via the TRAC system and have access to the latest build to update.

In terms of code updates, I've got a few questions. (sorry if TRAC does this already, but I'm not familiar with it)

What is in place currently to review changes to the codebase? Is there a system in place to do group reviews of code (before it is submitted to the svn)?

I believe that it is always good to have more eyes on code. It would probably be good to lay down a method to review all changes before they are submitted. The company I work for uses Review Board (http://review-board.org/). We find it very useful to keep track of what is being submitted to the code base, and catching small errors before they get entered into the SVN.

I think that going forward, and as more people (who may be inexperienced) join LinuxMCE. That LinuxMCE would benefit from a code review process.

[tschak909]

Right now, one of a few of us checks the code before it goes in. Simple, but we don't have very many people.

Please do not make it complicated.

-Thom

[dlewis]

Alaith, please create a wiki or create another post to discuss the usage of Review Board (possibly providing screenshots or videos).

[Alaith]

Alaith, please create a wiki or create another post to discuss the usage of Review Board (possibly providing screenshots or videos).

Done and Done ... http://wiki.linuxmce.org/index.php/Review_Board