Discussion: Release policy changes

[Aleksey Bragin]

		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.

[Klemens Friedl]

2006/12/9, Aleksey Bragin <aleksey(a)studiocerebral.com>om>:
>   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. 
I like the idea.

>   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 :)). 

 A release once per months, is exactly what we need. It means more
stable versions for normal tester / community member. So, there will
be no need for them to try out trunk-builds and ask questions ala
"bootcd don't build", "compile errors", etc.
We can submit more news events to media, which will hopefully result
in more new developers and more publicity in general.

As soon as the automatic regression testing system is active, plus
more up-to-date third party libs and some kernel fixes, ReactOS will
be a lot more stable than ever before and additionally more compatible
with WinNT 4/5x/6.

OpenOffice 1.x, AbiWord 2.x, OpenGL, SDL, ... we will then be useable
again, plus a lot more applications like Photoshop 3-7, etc.


Best regards,
Klemens Friedl

[Christoph von Wittich]

>   As soon as the automatic regression testing system is
> active, plus
>  more up-to-date third party libs and some kernel fixes, ReactOS will
>  be a lot more stable than ever before and additionally more compatible
>  with WinNT 4/5x/6.
>     
We need to get automated regression testing to work on linux  - and we 
need to upgrade the build servers before we can use it.
The average server load on the linux server is too high - you need to 
wait up to 10seconds before you can type into the console window.

Regards,
Christoph von Wittich

[Ged Murphy]

On 12/9/06, Aleksey Bragin <aleksey(a)studiocerebral.com> wrote:
>  
>                  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. 


I think everyone knows my view on this, I agree 100% with this change.

We are in Alpha, we don't need to polish every release:
1. it's killing our release cycle
2. it's taking the fun out of releasing
3. we get very little publicity

I think this could be the turning point we need.
A release is made no matter what, no arguments. The only think that stops it
is if there has been a huge regression which hasn't been fixed since the
last release (e.g. no networking)

I'm a happier person for seeing this email today :)

Ged "Release early, release often" Murphy.

Την Sat, 09 Dec 2006 17:13:24 +0200,ο(η) Ged Murphy <gedmurphy(a)gmail.com>  
έγραψε:

>   On 12/9/06, Aleksey Bragin
> <aleksey(a)studiocerebral.com> wrote:
> >  
> >                  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. 
>  
This is exactly what is needed to get more developers interested in the  
project, plus, increased publicity equals more testing which can only be a  
good thing.

- Stephen A

[Peter Ward]

    I definitely agree with releasing more often, however I have a bit 
of a different take on the idea. The way I see it a "real" release every 
3 months would be a good idea because then they are more likely to have 
some improvements that are news worthy and are less likely to get 
slammed in the media. Along with these tri-monthly releases there would 
be bi-weekly tested releases, like snapshots, I think these would work 
well with automatic regression testing.

    In any case releasing more often in whatever form is a good idea I 
think.

Regards
Peter

Aleksey Bragin wrote:
>   		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
>
>

[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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>

[Ged Murphy]

Timo Kreuzer wrote:
>   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: 
I think you missed the whole point of changing the release system.

Releasing shouldn't be time consuming, as Alekseys first email said
  "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."


Lets look at Wine's release process, every few weeks Julliard takes a 
snapshot of the source, builds it and makes both available online as a 
0.9.* release
A quick news article is normally written shortly after detailing the 
main changes (not every single change, this is unessesary).
Granted, Wine releases are generally very stable, but Wine are in Beta, 
currently sitting 1 major increment from the version 1 release.
We are at 0.3, currently 7 increments from a version 1 release. We are 
in Alpha, we don't need to worry too much about perfectly polished 
releases, that can be saved from the major releases (i.e. 3.0, 4.0, 5.0)

Our main interest is getting releases out as often as possible, and with 
as little effort as possible. Our releases are never going to be 
completely bug free at this stage, but I personally don't see that as a 
bad thing. 90% of patches we've accepted recently have been bug fixes, 
not new features. It seems to me that bugs are attracting devs.

It will happen on occasions that a release finds it's way out with a 
relatively serious bug which has been missed. This would be picked up by 
end users testing the releases. Again, I don't see a massive problem 
with this, the bug can be quickly fixed and a new release put out 
straight after with a little news article letting people know what is 
going on.
This might mean that we end up with things like 0.3.57, but is this 
really so bad? I quite like the idea of it. This isn't a web browser or 
text editor, it's a full operating system. 57 minor increments sounds 
entirely reasonable to me.

If it makes people happier, a note could be placed on the 'Download Now' 
area stating that ROS is incomplete, these releases are snapshots and to 
expect some bugs.

Ged.

[Ged Murphy]

On 12/10/06, Ged Murphy <gedmurphy(a)gmail.com> wrote:
>  
>  Tthat can be saved from the major releases (i.e. 3.0, 4.0, 5.0) 


Obvioulsly I meant 0.3, 0.4, 0.5

After all these years, it's finally caught me out too :(

[Andrew Flynn]

This automatic regression testing, and the build bot.... Where does the 
cpu time come from to do this work load, does ReactOS have some kind of 
distributed network processing in development? Is it possible to 
volunteer some of my own pc time to help?