[ros-dev] ReactOS development cycle

[Ged Murphy]

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



_______________________________________________
Ros-dev mailing list
Ros-dev at reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

 


_______________________________________________
Ros-dev mailing list
Ros-dev at reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.reactos.org/pipermail/ros-dev/attachments/20101011/dab78843/attachment-0001.htm>