[ros-dev] Discussion: Release policy changes

[Timo Kreuzer]

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 at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.reactos.org/pipermail/ros-dev/attachments/20061210/07cda4c1/attachment-0001.html