<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 13, 2014 at 4:50 AM, Peter Robinson <span dir="ltr"><<a href="mailto:pbrobinson@gmail.com" target="_blank">pbrobinson@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On Thu, Mar 13, 2014 at 12:37 AM, Manuel Quiñones <<a href="mailto:manuq@laptop.org">manuq@laptop.org</a>> wrote:<br>

> in my humble opinion, I would also like to see the feature freeze<br>
> delayed.  several features are almost done.<br>
<br>
</div>How long away is "almost done"? A few days, weeks? While I'm happy to<br>
see it delayed I want the delay defined so it doesn't roll on into an<br>
indefinite mess. I don't believe that is fair on either the release<br>
manager or the community at large.<br>
<br>
Daniel would you be amicable to stretching it out by a month so we<br>
have one more round of dev releases before entering freeze?<br>
<br>
To the people writing and reviewing is that enough rime to review and<br>
land the remaining features?<br>
<span class=""><font color="#888888"><br></font></span></blockquote><div><br></div><div>I agree, we want postpone the freeze, but define a date too.</div><div>I proposed add 3 weeks to the previous schedule,</div><div>but looking the time we need to decide, maybe one month have more sense.</div>
<div><br></div><div>Gonzalo</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888">
Peter<br>
</font></span><div class=""><div class="h5"><br>
> I see our community is still rearranging, and we need to put more<br>
> effort in reviews.  considering the load of PRs, we should embrace<br>
> pair-reviewing.<br>
><br>
> 2014-03-09 22:25 GMT-03:00 Daniel Narvaez <<a href="mailto:dwnarvaez@gmail.com">dwnarvaez@gmail.com</a>>:<br>
>> On 10 March 2014 01:48, Gonzalo Odiard <<a href="mailto:godiard@sugarlabs.org">godiard@sugarlabs.org</a>> wrote:<br>
>>><br>
>>><br>
>>><br>
>>> On Sun, Mar 9, 2014 at 9:40 PM, Daniel Narvaez <<a href="mailto:dwnarvaez@gmail.com">dwnarvaez@gmail.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> For what it's worth it would be a -1 from me. I would be fine to delay a<br>
>>>> bit to fix important bugs, but not to add more features, it seems to go<br>
>>>> completely against the rationale of time based releases. But that's just my<br>
>>>> opinion.<br>
>>>><br>
>>><br>
>>> Would be against the time based release, if the propose would be postpone<br>
>>> it indefinitely.<br>
>><br>
>><br>
>> I disagree. From <a href="https://wiki.gnome.org/ReleasePlanning/TimeBased" target="_blank">https://wiki.gnome.org/ReleasePlanning/TimeBased</a><br>
>><br>
>> --<br>
>><br>
>> Although we agree on rough aims for each major release, and attempt to<br>
>> achieve those aims, GNOME releases are time-based rather than feature-based.<br>
>> A roughly 6-month release cycle allows us to coordinate development of the<br>
>> features that have actually been implemented, allowing us to maintain the<br>
>> quality of the overall release without delaying everything because of one or<br>
>> two features. If a feature is not ready in time then the developers must not<br>
>> wait long to put it in the next major release. We have found that this<br>
>> encourages both high quality and rapid development compared to feature-based<br>
>> release schedules.<br>
>><br>
>> --<br>
>><br>
>> IMO delaying feature freeze is very clearly against that definition, in many<br>
>> ways.<br>
>><br>
>>><br>
>>> Many projects working with time based releases, like libreoffice, gnome or<br>
>>> fedora<br>
>>> adjust the schedules if they consider worth it.<br>
>><br>
>><br>
>> I honestly don't remember any of these projects making a decision to delay<br>
>> *feature* freeze two weeks after the deadline. I could be wrong of course, I<br>
>> have not followed every single releases of them.<br>
>><br>
>> More importantly, even if they did, it wouldn't mean their decision was<br>
>> consistent with the time based release schedule rationale. Sometimes it's<br>
>> worth to make compromises.<br>
>><br>
>> To articulate my point a bit more<br>
>><br>
>> 1 Delaying feature freeze after the deadline is obviously against time based<br>
>> release definition and rationale.<br>
>> 2 I don't see anything special with the current situation that would suggest<br>
>> we should compromise on our time based approach.<br>
>><br>
>> _______________________________________________<br>
>> Sugar-devel mailing list<br>
>> <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br>
>> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> .. manuq ..<br>
> _______________________________________________<br>
> Sugar-devel mailing list<br>
> <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br>
> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Gonzalo Odiard<br><br><div>SugarLabs - Learning Software for children<br></div></div>
</div></div>