11 Oct
2010
11 Oct
'10
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.