[Sugar-devel] Feature freeze

[Manuel Quiñones]

in my humble opinion, I would also like to see the feature freeze
delayed.  several features are almost done.

I see our community is still rearranging, and we need to put more
effort in reviews.  considering the load of PRs, we should embrace
pair-reviewing.

2014-03-09 22:25 GMT-03:00 Daniel Narvaez <dwnarvaez at gmail.com>:
> 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.
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
.. manuq ..