[Sugar-devel] Feature freeze

[Peter Robinson]

On Thu, Mar 13, 2014 at 12:37 AM, Manuel Quiñones <manuq at laptop.org> wrote:
> in my humble opinion, I would also like to see the feature freeze
> delayed.  several features are almost done.

How long away is "almost done"? A few days, weeks? While I'm happy to
see it delayed I want the delay defined so it doesn't roll on into an
indefinite mess. I don't believe that is fair on either the release
manager or the community at large.

Daniel would you be amicable to stretching it out by a month so we
have one more round of dev releases before entering freeze?

To the people writing and reviewing is that enough rime to review and
land the remaining features?

Peter

> 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 ..
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel