Author Topic: Alpha to Beta to GA Code Release strategy  (Read 4489 times)

Murdock

  • Guru
  • ****
  • Posts: 229
    • View Profile
Alpha to Beta to GA Code Release strategy
« on: July 20, 2009, 05:22:00 pm »
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

  • LinuxMCE God
  • ****
  • Posts: 5549
  • DOES work for LinuxMCE.
    • View Profile
Re: Alpha to Beta to GA Code Release strategy
« Reply #1 on: July 20, 2009, 07:24:13 pm »
I have no problem with this. Hari? Possy?

-Thom

Alaith

  • Newbie
  • *
  • Posts: 14
    • View Profile
Re: Alpha to Beta to GA Code Release strategy
« Reply #2 on: July 20, 2009, 11:17:22 pm »
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

  • LinuxMCE God
  • ****
  • Posts: 5549
  • DOES work for LinuxMCE.
    • View Profile
Re: Alpha to Beta to GA Code Release strategy
« Reply #3 on: July 21, 2009, 12:25:43 am »
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

  • Guru
  • ****
  • Posts: 401
    • View Profile
Re: Alpha to Beta to GA Code Release strategy
« Reply #4 on: July 21, 2009, 06:20:39 pm »
Alaith, please create a wiki or create another post to discuss the usage of Review Board (possibly providing screenshots or videos).

Alaith

  • Newbie
  • *
  • Posts: 14
    • View Profile
Re: Alpha to Beta to GA Code Release strategy
« Reply #5 on: July 27, 2009, 02:21:06 pm »
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