10 Dec
2006
10 Dec
'06
12:28 a.m.
I also think t would be good to release more often and with the new
regression testing in place it might be possible to do a monthly
release. But please keep in mind that releasing is always time consuming
and there should be a clear definition of when a release should be done
and what keeps a release to not be submitted.
Some suggestions:
* 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
o 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.
o There should be a selection for release-candidate or even
better a link for RC testing on the main BZ page.
o After a new branch the old BZ entries are deleted
* TC / RC should from time to time check the bugreports and
o confirm the bug: It's definately there and needs to be fixed
before release
o discard the bug: there is no need to fix the bug (it has
always been there or too hard to fix atm)
o request further investigation from other testers
o informs the devs for needed action
o mark a bug as resolved
* After some days when at least the major probs are fixed the
release get's released.
o How many days for testing?
o 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
o 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
o when a new release is branched
o when a new release is compiled
o when a new release bug report is commited
o when TC / RC wants to have further investigation of something
Greetings,
Timo (ThePhysicist / Physicus)
Aleksey Bragin schrieb:
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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev