We tried 3-month cycle and it simply doesnt work, unless you know a way to discipline devs.
2010/10/10 Ged Murphy <gedmur...@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 <alek...@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 >
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev