• Releasing shouldn't take much time of the devs. Maybe we should have a release coordinator (RC). He would select the best revision (after talking to the devs probably) and then branch it. He might write some short news entry for the release when it's finished (more news!). He decides when a new release is ready. He has to closely interact with the TC to make sure all the regressions are gone.
• Once per month the latest "good" revision is branched
• What is needed for the revision?
• The new branch will be compiled by BuildBot, so every tester can download an official iso and start testing
• If someone finds a regression / newly introduced bug he can submit it to bugzilla.
• There should be a selection for release-candidate or even better a link for RC testing on the main BZ page.
• After a new branch the old BZ entries are deleted
• TC / RC should from time to time check the bugreports and
• confirm the bug: It's definately there and needs to be fixed before release
• discard the bug: there is no need to fix the bug (it has always been there or too hard to fix atm)
• request further investigation from other testers
• informs the devs for needed action
• mark a bug as resolved
  
• After some days when at least the major probs are fixed the release get's released.
• How many days for testing?
• What's the limit if there are still regressions?
• There should be a wiki page that says what needs to be tested / what worked on earlier releases
• a page for every release that inherits the entries of the oder releases and most entries should be marked as passed.
  
• Releases should be working on real Hw as they did before (they worked great for me on my Athlon, would like to do further testing!)
• Testers might be added to a mailing list that informs them
• when a new release is branched
• when a new release is compiled
• when a new release bug report is commited
• when TC / RC wants to have further investigation of something

		Hello,
I'd like to hear opinions regarding the change in release policy.

The proposition:
Release happens on a strict time basis, like once per month. That  
means, at the end of the month we look for the best revision inside  
this month (probably which is closer to the end of the month), branch  
from it, apply all fixes (if any), and release.

Disadvantage: a few coming releases' quality will be overall lower,  
there might be things like 0.3.25 (if release frequency is set too  
high, and this is not a disadvantage actually).

Advantages: in the long run quality goes up, more developers due to  
higher release rate, more publicity, people will finally realize it's  
an alpha product, more bugs reported, no signs of a dead project (I  
doubt there are healthy projects doing 1 release per year :)).

Any thoughts are appreciated.


With the best regards,
Aleksey Bragin.

_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev