[Sugar-devel] Feature freeze

[Daniel Narvaez]

On 10 March 2014 01:48, Gonzalo Odiard <godiard at sugarlabs.org> wrote:

>
>
> On Sun, Mar 9, 2014 at 9:40 PM, Daniel Narvaez <dwnarvaez at gmail.com>wrote:
>
>> For what it's worth it would be a -1 from me. I would be fine to delay a
>> bit to fix important bugs, but not to add more features, it seems to go
>> completely against the rationale of time based releases. But that's just my
>> opinion.
>>
>>
> Would be against the time based release, if the propose would be postpone
> it indefinitely.
>

I disagree. From https://wiki.gnome.org/ReleasePlanning/TimeBased

--

Although we agree on rough aims for each major release, and attempt to
achieve those aims, GNOME releases are time-based rather than
feature-based. A roughly 6-month release cycle allows us to coordinate
development of the features that have actually been implemented, allowing
us to maintain the quality of the overall release without delaying
everything because of one or two features. If a feature is not ready in
time then the developers must not wait long to put it in the next major
release. We have found that this encourages both high quality and rapid
development compared to feature-based release schedules.

--

IMO delaying feature freeze is very clearly against that definition, in
many ways.


> Many projects working with time based releases, like libreoffice, gnome or
> fedora
> adjust the schedules if they consider worth it.
>

I honestly don't remember any of these projects making a decision to delay
*feature* freeze two weeks after the deadline. I could be wrong of course,
I have not followed every single releases of them.

More importantly, even if they did, it wouldn't mean their decision was
consistent with the time based release schedule rationale. Sometimes it's
worth to make compromises.

To articulate my point a bit more

1 Delaying feature freeze after the deadline is obviously against time
based release definition and rationale.
2 I don't see anything special with the current situation that would
suggest we should compromise on our time based approach.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140310/ea730e30/attachment.html>