[Sugar-devel] Feature freeze

[Gonzalo Odiard]

On Thu, Mar 13, 2014 at 4:50 AM, Peter Robinson <pbrobinson at gmail.com>wrote:

> 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?
>
>
I agree, we want postpone the freeze, but define a date too.
I proposed add 3 weeks to the previous schedule,
but looking the time we need to decide, maybe one month have more sense.

Gonzalo





> 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
>



-- 
Gonzalo Odiard

SugarLabs - Learning Software for children
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140313/7d24be72/attachment.html>