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.
2006/12/9, Aleksey Bragin aleksey@studiocerebral.com:
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
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
On 12/9/06, Aleksey Bragin aleksey@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@gmail.com έγραψε:
On 12/9/06, Aleksey Bragin aleksey@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
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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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.
On 12/10/06, Ged Murphy gedmurphy@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 :(
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?
-
Aleksey Bragin -
Andrew Flynn -
Christoph von Wittich -
Ged Murphy -
Klemens Friedl -
Peter Ward -
stapostol＠gmail.com -
Timo Kreuzer