I think its a good time to discuss current development cycle. It become clear to me, that there is no way we can currently adhere to 3 months development cycle. Its pointless to stick to something we managed to succeed only once or twice. Agreeing with the fact we do need releases, for various reasons, i would like to propose a new, longer cycle.
The most apparent choices to me are 4 and 6 month ones. At least half of the cycle would be spent on all out development, with the following half turning its concentration to stabilizing trunk, searching for regressions and bugs, fixing them. The cycles would be separated by branching the release version. The actual release would be taking place on the first month of the NEXT DEVELOPMENT cycle. The actual emergency hacking, writing changelog etc. One month is more than enough, to release two RC (at the branching and next one - after two weeks). End of the month must result in final release. RC should be rather released internally for testing purposes on a default iso.
The actual proposals are:
4 months:
month 1: Development on version x. At the same time, the Release x-1 is to be final-tested, emergency-hacked, changelogged and shipped. The deadline is end of month 1. month 2: Development on version x. All development that can affect trunk stability, but also will not be shipped with the release X should end or be limited to branch only by the end of this month; month 3: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Finalizing sub-projects that are to be included in release x; month 4; No new functionality/code, bug-fixing and hunting regressions. This month should end with branching for release x;
6 months:
month 1: Development on version x. At the same time, the Release x-1 is to be final-tested, emergency-hacked, changelogged and shipped. The deadline is end of month 1. month 2: Development on version x; month 3: Development on version x. All development that can affect trunk stability, but also will not be shipped with the release X should end or be limited to branch only by the end of this month; month 4: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Ongoing development work only for features that are to be shipped with release x; month 5: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Finalizing sub-projects that are to be included in release x; month 6: No new functionality/code, bug-fixing and hunting regressions. This month should end with branching for release x;
I approve of anything that we will stick to. A six month cycle sounds good.
On Sat, Oct 9, 2010 at 9:14 AM, Olaf Siejka caemyr@gmail.com wrote:
I think its a good time to discuss current development cycle. It become clear to me, that there is no way we can currently adhere to 3 months development cycle. Its pointless to stick to something we managed to succeed only once or twice. Agreeing with the fact we do need releases, for various reasons, i would like to propose a new, longer cycle.
The most apparent choices to me are 4 and 6 month ones. At least half of the cycle would be spent on all out development, with the following half turning its concentration to stabilizing trunk, searching for regressions and bugs, fixing them. The cycles would be separated by branching the release version. The actual release would be taking place on the first month of the NEXT DEVELOPMENT cycle. The actual emergency hacking, writing changelog etc. One month is more than enough, to release two RC (at the branching and next one - after two weeks). End of the month must result in final release. RC should be rather released internally for testing purposes on a default iso.
The actual proposals are:
4 months:
month 1: Development on version x. At the same time, the Release x-1 is to be final-tested, emergency-hacked, changelogged and shipped. The deadline is end of month 1. month 2: Development on version x. All development that can affect trunk stability, but also will not be shipped with the release X should end or be limited to branch only by the end of this month; month 3: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Finalizing sub-projects that are to be included in release x; month 4; No new functionality/code, bug-fixing and hunting regressions. This month should end with branching for release x;
6 months:
month 1: Development on version x. At the same time, the Release x-1 is to be final-tested, emergency-hacked, changelogged and shipped. The deadline is end of month 1. month 2: Development on version x; month 3: Development on version x. All development that can affect trunk stability, but also will not be shipped with the release X should end or be limited to branch only by the end of this month; month 4: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Ongoing development work only for features that are to be shipped with release x; month 5: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Finalizing sub-projects that are to be included in release x; month 6: No new functionality/code, bug-fixing and hunting regressions. This month should end with branching for release x;
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I support 4 month cycle, the 3 months turned out to be unrealistic, while 6 months is too long time between releases (we are speaking about normal development, not kernel rewrites which have to take that long time).
WBR, Aleksey Bragin.
On Oct 9, 2010, at 5:14 PM, Olaf Siejka wrote:
I think its a good time to discuss current development cycle. It become clear to me, that there is no way we can currently adhere to 3 months development cycle. Its pointless to stick to something we managed to succeed only once or twice. Agreeing with the fact we do need releases, for various reasons, i would like to propose a new, longer cycle.
The most apparent choices to me are 4 and 6 month ones. At least half of the cycle would be spent on all out development, with the following half turning its concentration to stabilizing trunk, searching for regressions and bugs, fixing them. The cycles would be separated by branching the release version. The actual release would be taking place on the first month of the NEXT DEVELOPMENT cycle. The actual emergency hacking, writing changelog etc. One month is more than enough, to release two RC (at the branching and next one - after two weeks). End of the month must result in final release. RC should be rather released internally for testing purposes on a default iso.
The actual proposals are:
4 months:
month 1: Development on version x. At the same time, the Release x-1 is to be final-tested, emergency-hacked, changelogged and shipped. The deadline is end of month 1. month 2: Development on version x. All development that can affect trunk stability, but also will not be shipped with the release X should end or be limited to branch only by the end of this month; month 3: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Finalizing sub-projects that are to be included in release x; month 4; No new functionality/code, bug-fixing and hunting regressions. This month should end with branching for release x;
6 months:
month 1: Development on version x. At the same time, the Release x-1 is to be final-tested, emergency-hacked, changelogged and shipped. The deadline is end of month 1. month 2: Development on version x; month 3: Development on version x. All development that can affect trunk stability, but also will not be shipped with the release X should end or be limited to branch only by the end of this month; month 4: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Ongoing development work only for features that are to be shipped with release x; month 5: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Finalizing sub-projects that are to be included in release x; month 6: No new functionality/code, bug-fixing and hunting regressions. This month should end with branching for release x; _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I still think you should stick to a 3 month cycle. If you want a stable tree and good exposure, you need to release often. It hasn't gone to plan in the past but I think things should start to stabalize going forward.
6 months is definitely not an option IMO.
Ged.
On 10 October 2010 12:00, Aleksey Bragin aleksey@reactos.org wrote:
I support 4 month cycle, the 3 months turned out to be unrealistic, while 6 months is too long time between releases (we are speaking about normal development, not kernel rewrites which have to take that long time).
WBR, Aleksey Bragin.
On Oct 9, 2010, at 5:14 PM, Olaf Siejka wrote:
I think its a good time to discuss current development cycle.
It become clear to me, that there is no way we can currently adhere to 3 months development cycle. Its pointless to stick to something we managed to succeed only once or twice. Agreeing with the fact we do need releases, for various reasons, i would like to propose a new, longer cycle.
The most apparent choices to me are 4 and 6 month ones. At least half of the cycle would be spent on all out development, with the following half turning its concentration to stabilizing trunk, searching for regressions and bugs, fixing them. The cycles would be separated by branching the release version. The actual release would be taking place on the first month of the NEXT DEVELOPMENT cycle. The actual emergency hacking, writing changelog etc. One month is more than enough, to release two RC (at the branching and next one - after two weeks). End of the month must result in final release. RC should be rather released internally for testing purposes on a default iso.
The actual proposals are:
4 months:
month 1: Development on version x. At the same time, the Release x-1 is to be final-tested, emergency-hacked, changelogged and shipped. The deadline is end of month 1. month 2: Development on version x. All development that can affect trunk stability, but also will not be shipped with the release X should end or be limited to branch only by the end of this month; month 3: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Finalizing sub-projects that are to be included in release x; month 4; No new functionality/code, bug-fixing and hunting regressions. This month should end with branching for release x;
6 months:
month 1: Development on version x. At the same time, the Release x-1 is to be final-tested, emergency-hacked, changelogged and shipped. The deadline is end of month 1. month 2: Development on version x; month 3: Development on version x. All development that can affect trunk stability, but also will not be shipped with the release X should end or be limited to branch only by the end of this month; month 4: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Ongoing development work only for features that are to be shipped with release x; month 5: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Finalizing sub-projects that are to be included in release x; month 6: No new functionality/code, bug-fixing and hunting regressions. This month should end with branching for release x; _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
We tried 3-month cycle and it simply doesnt work, unless you know a way to discipline devs.
2010/10/10 Ged Murphy gedmurphy@gmail.com
I still think you should stick to a 3 month cycle. If you want a stable tree and good exposure, you need to release often. It hasn't gone to plan in the past but I think things should start to stabalize going forward.
6 months is definitely not an option IMO.
Ged.
On 10 October 2010 12:00, Aleksey Bragin aleksey@reactos.org wrote:
I support 4 month cycle, the 3 months turned out to be unrealistic, while 6 months is too long time between releases (we are speaking about normal development, not kernel rewrites which have to take that long time).
WBR, Aleksey Bragin.
On Oct 9, 2010, at 5:14 PM, Olaf Siejka wrote:
I think its a good time to discuss current development cycle.
It become clear to me, that there is no way we can currently adhere to 3 months development cycle. Its pointless to stick to something we managed to succeed only once or twice. Agreeing with the fact we do need releases, for various reasons, i would like to propose a new, longer cycle.
The most apparent choices to me are 4 and 6 month ones. At least half of the cycle would be spent on all out development, with the following half turning its concentration to stabilizing trunk, searching for regressions and bugs, fixing them. The cycles would be separated by branching the release version. The actual release would be taking place on the first month of the NEXT DEVELOPMENT cycle. The actual emergency hacking, writing changelog etc. One month is more than enough, to release two RC (at the branching and next one - after two weeks). End of the month must result in final release. RC should be rather released internally for testing purposes on a default iso.
The actual proposals are:
4 months:
month 1: Development on version x. At the same time, the Release x-1 is to be final-tested, emergency-hacked, changelogged and shipped. The deadline is end of month 1. month 2: Development on version x. All development that can affect trunk stability, but also will not be shipped with the release X should end or be limited to branch only by the end of this month; month 3: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Finalizing sub-projects that are to be included in release x; month 4; No new functionality/code, bug-fixing and hunting regressions. This month should end with branching for release x;
6 months:
month 1: Development on version x. At the same time, the Release x-1 is to be final-tested, emergency-hacked, changelogged and shipped. The deadline is end of month 1. month 2: Development on version x; month 3: Development on version x. All development that can affect trunk stability, but also will not be shipped with the release X should end or be limited to branch only by the end of this month; month 4: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Ongoing development work only for features that are to be shipped with release x; month 5: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Finalizing sub-projects that are to be included in release x; month 6: No new functionality/code, bug-fixing and hunting regressions. This month should end with branching for release x; _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
A 3 month cycle is ridiculous and IMO unnecessary. I think it will be too much work on the release engineers, and very little (if any) actual development work will end up taking place, and things will be rushed with hack fixes and what not, where time could have been better spent coming up with more elegant solutions to such problems.
Six months sounds a little better.
On Mon, 11 Oct 2010 18:08:28 +1100, Olaf Siejka caemyr@gmail.com wrote:
We tried 3-month cycle and it simply doesnt work, unless you know a way to discipline devs.
2010/10/10 Ged Murphy gedmurphy@gmail.com
I still think you should stick to a 3 month cycle. If you want a stable tree and good exposure, you need to release often. It hasn't gone to plan in the past but I think things should start to stabalize going forward.
6 months is definitely not an option IMO.
Ged.
On 10 October 2010 12:00, Aleksey Bragin aleksey@reactos.org wrote:
I support 4 month cycle, the 3 months turned out to be unrealistic, while 6 months is too long time between releases (we are speaking about normal development, not kernel rewrites which have to take that long time).
WBR, Aleksey Bragin.
On Oct 9, 2010, at 5:14 PM, Olaf Siejka wrote:
I think its a good time to discuss current development cycle.
It become clear to me, that there is no way we can currently adhere to 3 months development cycle. Its pointless to stick to something we managed to succeed only once or twice. Agreeing with the fact we do need releases, for various reasons, i would like to propose a new, longer cycle.
The most apparent choices to me are 4 and 6 month ones. At least half of the cycle would be spent on all out development, with the following half turning its concentration to stabilizing trunk, searching for regressions and bugs, fixing them. The cycles would be separated by branching the release version. The actual release would be taking place on the first month of the NEXT DEVELOPMENT cycle. The actual emergency hacking, writing changelog etc. One month is more than enough, to release two RC (at the branching and next one - after two weeks). End of the month must result in final release. RC should be rather released internally for testing purposes on a default iso.
The actual proposals are:
4 months:
month 1: Development on version x. At the same time, the Release x-1 is to be final-tested, emergency-hacked, changelogged and shipped. The deadline is end of month 1. month 2: Development on version x. All development that can affect trunk stability, but also will not be shipped with the release X should end or be limited to branch only by the end of this month; month 3: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Finalizing sub-projects that are to be included in release x; month 4; No new functionality/code, bug-fixing and hunting regressions. This month should end with branching for release x;
6 months:
month 1: Development on version x. At the same time, the Release x-1 is to be final-tested, emergency-hacked, changelogged and shipped. The deadline is end of month 1. month 2: Development on version x; month 3: Development on version x. All development that can affect trunk stability, but also will not be shipped with the release X should end or be limited to branch only by the end of this month; month 4: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Ongoing development work only for features that are to be shipped with release x; month 5: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Finalizing sub-projects that are to be included in release x; month 6: No new functionality/code, bug-fixing and hunting regressions. This month should end with branching for release x; _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
We tried it at the wrong time, trunk wasn't ready for it.
If you go back over the previous discussions we had on the topic a few years ago, you'll see that what was discussed makes good development sense.
Ged.
From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Olaf Siejka Sent: 11 October 2010 08:08 To: ReactOS Development List Subject: Re: [ros-dev] ReactOS development cycle
We tried 3-month cycle and it simply doesnt work, unless you know a way to discipline devs.
2010/10/10 Ged Murphy gedmurphy@gmail.com
I still think you should stick to a 3 month cycle.
If you want a stable tree and good exposure, you need to release often.
It hasn't gone to plan in the past but I think things should start to stabalize going forward.
6 months is definitely not an option IMO.
Ged.
On 10 October 2010 12:00, Aleksey Bragin aleksey@reactos.org wrote:
I support 4 month cycle, the 3 months turned out to be unrealistic, while 6 months is too long time between releases (we are speaking about normal development, not kernel rewrites which have to take that long time).
WBR, Aleksey Bragin.
On Oct 9, 2010, at 5:14 PM, Olaf Siejka wrote:
I think its a good time to discuss current development cycle. It become clear to me, that there is no way we can currently adhere to 3 months development cycle. Its pointless to stick to something we managed to succeed only once or twice. Agreeing with the fact we do need releases, for various reasons, i would like to propose a new, longer cycle.
The most apparent choices to me are 4 and 6 month ones. At least half of the cycle would be spent on all out development, with the following half turning its concentration to stabilizing trunk, searching for regressions and bugs, fixing them. The cycles would be separated by branching the release version. The actual release would be taking place on the first month of the NEXT DEVELOPMENT cycle. The actual emergency hacking, writing changelog etc. One month is more than enough, to release two RC (at the branching and next one - after two weeks). End of the month must result in final release. RC should be rather released internally for testing purposes on a default iso.
The actual proposals are:
4 months:
month 1: Development on version x. At the same time, the Release x-1 is to be final-tested, emergency-hacked, changelogged and shipped. The deadline is end of month 1. month 2: Development on version x. All development that can affect trunk stability, but also will not be shipped with the release X should end or be limited to branch only by the end of this month; month 3: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Finalizing sub-projects that are to be included in release x; month 4; No new functionality/code, bug-fixing and hunting regressions. This month should end with branching for release x;
6 months:
month 1: Development on version x. At the same time, the Release x-1 is to be final-tested, emergency-hacked, changelogged and shipped. The deadline is end of month 1. month 2: Development on version x; month 3: Development on version x. All development that can affect trunk stability, but also will not be shipped with the release X should end or be limited to branch only by the end of this month; month 4: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Ongoing development work only for features that are to be shipped with release x; month 5: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Finalizing sub-projects that are to be included in release x; month 6: No new functionality/code, bug-fixing and hunting regressions. This month should end with branching for release x;
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I do agree with Wax in general, that any cycle will be ok provided that we can stick to it.
Three month cycle would be (more/less):
- 6 weeks of pure development (and first 4 weeks - release of the x-1 version); - 6 weeks of stabilising trunk, bugfixing, plus some finishing work on features that will be included in this release;
Seems awfully short
Regards
2010/10/11 Ged Murphy gedmurphy@gmail.com
We tried it at the wrong time, trunk wasn’t ready for it.
If you go back over the previous discussions we had on the topic a few years ago, you’ll see that what was discussed makes good development sense.
Ged.
It does sound quite short to me too. I would be quite surprised if one can even stick to this cycle. Remember that this is an operating system after all.
On Mon, 11 Oct 2010 19:14:17 +1100, Olaf Siejka caemyr@gmail.com wrote:
I do agree with Wax in general, that any cycle will be ok provided that we can stick to it.
Three month cycle would be (more/less):
- 6 weeks of pure development (and first 4 weeks - release of the x-1
version);
- 6 weeks of stabilising trunk, bugfixing, plus some finishing work on
features that will be included in this release;
Seems awfully short
Regards
2010/10/11 Ged Murphy gedmurphy@gmail.com
We tried it at the wrong time, trunk wasn’t ready for it.
If you go back over the previous discussions we had on the topic a few years ago, you’ll see that what was discussed makes >>good development sense.
Ged.
A stable trunk should be an ongoing battle, not something reserved for release time.
There shouldn't be more than a weeks worth of release work required (the release itself is no more than a few hours work).
Anything which jeopardises this should be done in a branch.
http://en.wikipedia.org/wiki/Release_early,_release_often
It's a tried and proven method used in most large open source projects and reactos is no exception
Ged.
From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Olaf Siejka Sent: 11 October 2010 09:14 To: ReactOS Development List Subject: Re: [ros-dev] ReactOS development cycle
I do agree with Wax in general, that any cycle will be ok provided that we can stick to it.
Three month cycle would be (more/less):
- 6 weeks of pure development (and first 4 weeks - release of the x-1 version);
- 6 weeks of stabilising trunk, bugfixing, plus some finishing work on features that will be included in this release;
Seems awfully short
Regards
2010/10/11 Ged Murphy gedmurphy@gmail.com
We tried it at the wrong time, trunk wasn't ready for it.
If you go back over the previous discussions we had on the topic a few years ago, you'll see that what was discussed makes good development sense.
Ged.
Remember that a lot of open-source projects are not in pre-alpha anymore. Also, they may be very small projects with few developers, or very large projects with many developers. Often as well, many which adopt such a cycle do not have to worry about compatibility with closed-source products.
A disadvantage to the users is also present in the same link you provided: "Disadvantages to this release model include the possibility of more frequent crashes or even data loss, and that end users must update their software more often."
On Mon, 11 Oct 2010 20:14:26 +1100, Ged Murphy gedmurphy@gmail.com wrote:
A stable trunk should be an ongoing battle, not something reserved for release time.
There shouldn’t be more than a weeks worth of release work required (the release itself is no more than a few hours work).
Anything which jeopardises this should be done in a branch.
http://en.wikipedia.org/wiki/Release_early,_release_often
It’s a tried and proven method used in most large open source projects and reactos is no exception
Ged.
From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Olaf Siejka Sent: 11 October 2010 09:14 To: ReactOS Development List Subject: Re: [ros-dev] ReactOS development cycle
I do agree with Wax in general, that any cycle will be ok provided that we can stick to it.
Three month cycle would be (more/less):
- 6 weeks of pure development (and first 4 weeks - release of the x-1
version);
- 6 weeks of stabilising trunk, bugfixing, plus some finishing work on
features that will be included in this release;
Seems awfully short
Regards
2010/10/11 Ged Murphy gedmurphy@gmail.com
We tried it at the wrong time, trunk wasn’t ready for it.
If you go back over the previous discussions we had on the topic a few years ago, you’ll see that what was discussed makes >good development sense.
Ged.
I am sorry to point out that our devs (no pointing out) still fail to do something as simple as observing their commit on buildbot if it causes any problem. I`m not even talking about things more complicated, like not commiting again without first checking if previous commit was built fine. Also, devs do not check trunk status before commiting, they often commit when tree build is broken. All of this makes subsequent testing considerably harder, taking more time and let me remind you that we still have less active testers than active devs. This is just an example, straight off my mind. If we cant have such little, easy details sorted out, we cannot have an outgoing battle for trunk stability, as this value does not seem to be in any regard amongst ReactOS devs.
Regards
2010/10/11 Ged Murphy gedmurphy@gmail.com
A stable trunk should be an ongoing battle, not something reserved for release time.
There shouldn’t be more than a weeks worth of release work required (the release itself is no more than a few hours work).
Anything which jeopardises this should be done in a branch.
http://en.wikipedia.org/wiki/Release_early,_release_often
It’s a tried and proven method used in most large open source projects and reactos is no exception
Ged
I completely agree, it's a problem that's become more apparent in recent years.
You have to wonder whether it's better to try and fix the root of the problem, or if it's worth hacking around the problem by introducing less effective development models.
I've always been a supporter of the former, even though some of my ideas to tackle it haven't always been popular with all the devs.
Ged.
From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Olaf Siejka Sent: 11 October 2010 10:25 To: ReactOS Development List Subject: Re: [ros-dev] ReactOS development cycle
I am sorry to point out that our devs (no pointing out) still fail to do something as simple as observing their commit on buildbot if it causes any problem. I`m not even talking about things more complicated, like not commiting again without first checking if previous commit was built fine. Also, devs do not check trunk status before commiting, they often commit when tree build is broken. All of this makes subsequent testing considerably harder, taking more time and let me remind you that we still have less active testers than active devs. This is just an example, straight off my mind. If we cant have such little, easy details sorted out, we cannot have an outgoing battle for trunk stability, as this value does not seem to be in any regard amongst ReactOS devs.
Regards
2010/10/11 Ged Murphy gedmurphy@gmail.com
A stable trunk should be an ongoing battle, not something reserved for release time.
There shouldn't be more than a weeks worth of release work required (the release itself is no more than a few hours work).
Anything which jeopardises this should be done in a branch.
http://en.wikipedia.org/wiki/Release_early,_release_often
It's a tried and proven method used in most large open source projects and reactos is no exception
Ged
I'd vote for a six months release cycle. ...in case we can actually enforce it. ----- Original Message ----- From: Olaf Siejka To: ReactOS Development List Sent: Saturday, October 09, 2010 3:14 PM Subject: [ros-dev] ReactOS development cycle
I think its a good time to discuss current development cycle. It become clear to me, that there is no way we can currently adhere to 3 months development cycle. Its pointless to stick to something we managed to succeed only once or twice.
Agreeing with the fact we do need releases, for various reasons, i would like to propose a new, longer cycle.
The most apparent choices to me are 4 and 6 month ones. At least half of the cycle would be spent on all out development, with the following half turning its concentration to stabilizing trunk, searching for regressions and bugs, fixing them. The cycles would be separated by branching the release version. The actual release would be taking place on the first month of the NEXT DEVELOPMENT cycle. The actual emergency hacking, writing changelog etc. One month is more than enough, to release two RC (at the branching and next one - after two weeks). End of the month must result in final release. RC should be rather released internally for testing purposes on a default iso.
The actual proposals are:
4 months:
month 1: Development on version x. At the same time, the Release x-1 is to be final-tested, emergency-hacked, changelogged and shipped. The deadline is end of month 1. month 2: Development on version x. All development that can affect trunk stability, but also will not be shipped with the release X should end or be limited to branch only by the end of this month; month 3: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Finalizing sub-projects that are to be included in release x; month 4; No new functionality/code, bug-fixing and hunting regressions. This month should end with branching for release x;
6 months:
month 1: Development on version x. At the same time, the Release x-1 is to be final-tested, emergency-hacked, changelogged and shipped. The deadline is end of month 1. month 2: Development on version x; month 3: Development on version x. All development that can affect trunk stability, but also will not be shipped with the release X should end or be limited to branch only by the end of this month; month 4: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Ongoing development work only for features that are to be shipped with release x; month 5: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Finalizing sub-projects that are to be included in release x; month 6: No new functionality/code, bug-fixing and hunting regressions. This month should end with branching for release x;
------------------------------------------------------------------------------
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
+1 for a 6-months cycle.... 0.3.12 is actually taking more than 4 months (even more than 6 months, but isnt usual)
On Sun, Oct 10, 2010 at 1:09 PM, Kamil Hornicek kamil.hornicek@reactos.orgwrote:
I'd vote for a six months release cycle. ...in case we can actually enforce it.
----- Original Message ----- *From:* Olaf Siejka caemyr@gmail.com *To:* ReactOS Development List ros-dev@reactos.org *Sent:* Saturday, October 09, 2010 3:14 PM *Subject:* [ros-dev] ReactOS development cycle
I think its a good time to discuss current development cycle. It become clear to me, that there is no way we can currently adhere to 3 months development cycle. Its pointless to stick to something we managed to succeed only once or twice. Agreeing with the fact we do need releases, for various reasons, i would like to propose a new, longer cycle.
The most apparent choices to me are 4 and 6 month ones. At least half of the cycle would be spent on all out development, with the following half turning its concentration to stabilizing trunk, searching for regressions and bugs, fixing them. The cycles would be separated by branching the release version. The actual release would be taking place on the first month of the NEXT DEVELOPMENT cycle. The actual emergency hacking, writing changelog etc. One month is more than enough, to release two RC (at the branching and next one - after two weeks). End of the month must result in final release. RC should be rather released internally for testing purposes on a default iso.
The actual proposals are:
4 months:
month 1: Development on version x. At the same time, the Release x-1 is to be final-tested, emergency-hacked, changelogged and shipped. The deadline is end of month 1. month 2: Development on version x. All development that can affect trunk stability, but also will not be shipped with the release X should end or be limited to branch only by the end of this month; month 3: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Finalizing sub-projects that are to be included in release x; month 4; No new functionality/code, bug-fixing and hunting regressions. This month should end with branching for release x;
6 months:
month 1: Development on version x. At the same time, the Release x-1 is to be final-tested, emergency-hacked, changelogged and shipped. The deadline is end of month 1. month 2: Development on version x; month 3: Development on version x. All development that can affect trunk stability, but also will not be shipped with the release X should end or be limited to branch only by the end of this month; month 4: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Ongoing development work only for features that are to be shipped with release x; month 5: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Finalizing sub-projects that are to be included in release x; month 6: No new functionality/code, bug-fixing and hunting regressions. This month should end with branching for release x;
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi,
I just want drop a note regarding development cycle. As long as developers are volunteers we can't plan development cycles like companies with similar deadlines. Therefore I want to suggest following ideas: - keep trunk always clean (no breakage, no freeze) - make/(re)define a strategy to create releases and merge back changes to trunk - split up between solutions and release-hackfixes - set effort of changes to create a release (release related additional changes) in relation to release cycle time - in general force continuous-integration-development like SCRUM-approach
We aren't enough developers for more sophisticated methods and to be honest we have (sometimes) to appear changes as bigger as they are. So we should apply KISS principle and follow the strategy to be able to make a release (almost) every time from trunk. For one of the next releases I suggest a "bug-fixing-only" release to wipe out the most annoying hackfixes and/or to reduce the bug list significantly. The system is quiet stable and we don't need to add new features in hasty manner. Maybe we can continue with applying waiting patches, or improve it for an integration.
Regarding the time frame, it's unimportant whether 3 months cycle or 6 months cycle, important for me is that we don't deviate from the cycle to much.
Best regards
Matthias
-
Adam Kachwalla -
Aleksey Bragin -
Ged Murphy -
Javier Agustìn Fernàndez Arroyo -
Kamil Hornicek -
Matthias Kupfer -
Olaf Siejka -
WaxDragon