<div dir="ltr">On 10 March 2014 01:48, Gonzalo Odiard <span dir="ltr"><<a href="mailto:godiard@sugarlabs.org" target="_blank">godiard@sugarlabs.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On Sun, Mar 9, 2014 at 9:40 PM, Daniel Narvaez <span dir="ltr"><<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.<br>


</div></div><div class="gmail_extra"><div><div><br></div></div></div></blockquote><div><br></div></div><div>Would be against the time based release, if the propose would be postpone it indefinitely.</div><div></div></div>
</div></div></blockquote><div><br></div><div>I disagree. From <a href="https://wiki.gnome.org/ReleasePlanning/TimeBased">https://wiki.gnome.org/ReleasePlanning/TimeBased</a><br><br>--<br><br>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. <br><br>--<br><br></div><div>IMO delaying feature freeze is very clearly against that definition, in many ways.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Many projects working with time based releases, like libreoffice, gnome or fedora </div>
<div>adjust the schedules if they consider worth it.<br></div></div></div></div></blockquote><div><br></div><div>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.<br>
<br></div><div>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.<br><br></div><div>To articulate my point a bit more<br>
<br></div><div>1 Delaying feature freeze after the deadline is obviously against time based release definition and rationale.<br></div><div>2 I don't see anything special with the current situation that would suggest we should compromise on our time based approach.<br>
</div></div></div></div>