9 Oct
2010
9 Oct
'10
1:14 p.m.
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;
9 Oct
9 Oct
3:44 p.m.
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(a)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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
--
<+encoded> if you square a unicorn do you get a real animal?
10 Oct
10 Oct
11 a.m.
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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
2:37 p.m.
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(a)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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
11 Oct
11 Oct
7:08 a.m.
We tried 3-month cycle and it simply doesnt work, unless you know a way to
discipline devs.
2010/10/10 Ged Murphy <gedmurphy(a)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(a)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.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
7:13 a.m.
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(a)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(a)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(a)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(a)reactos.org
>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>
>>
>>
>> _______________________________________________
>> Ros-dev mailing list
>> Ros-dev(a)reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
--
Give a man a fish and he will eat for a day.
Teach a man to fish and he will eat for a lifetime.
Give a man religion and he will die praying for a fish.
8:02 a.m.
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(a)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(a)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(a)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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
8:14 a.m.
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(a)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.
8:17 a.m.
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(a)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(a)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.
--
Give a man a fish and he will eat for a day.
Teach a man to fish and he will eat for a lifetime.
Give a man religion and he will die praying for a fish.
9:14 a.m.
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(a)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(a)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.
9:21 a.m.
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(a)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(a)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(a)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.
--
Give a man a fish and he will eat for a day.
Teach a man to fish and he will eat for a lifetime.
Give a man religion and he will die praying for a fish.
9:24 a.m.
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(a)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
9:36 a.m.
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(a)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(a)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
10 Oct
10 Oct
11:09 a.m.
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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
2:29 p.m.
+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(a)reactos.org>wrote;wrote:
I'd vote for a six months release cycle. ...in
case we can actually
enforce it.
----- Original Message -----
*From:* Olaf Siejka <caemyr(a)gmail.com>
*To:* ReactOS Development List <ros-dev(a)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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
11 Oct
11 Oct
9:01 a.m.
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
--
Matthias Kupfer phone +49 371 236 46 52
Wilhelm-Firl-Straße 21 mobile +49 160 859 43 54
09122 Chemnitz, Germany
5189
days inactive
5191
days old
15 comments
8 participants
participants (8)
-
Adam Kachwalla -
Aleksey Bragin -
Ged Murphy -
Javier Agustìn Fernàndez Arroyo -
Kamil Hornicek -
Matthias Kupfer -
Olaf Siejka -
WaxDragon