+1, but hopefully only those features already proposed are allowed. In future lets move the code freeze date before the freeze date :), makes life easier for folks scrambling to get their feature in.
Thanks, -Nitin On 04/06/13 10:47 AM, "Prasanna Santhanam" <t...@apache.org> wrote: >+0 - similar concerns as Sebastien. I hope that we also don't >introduce any new unproposed features, or architectural changes to 4.2 >at the end of the cycle, which this extension still is. > >Also - it's probably worth discussing a time based release with >milestones beyond which feature proposals are frozen and ones after >which the code is frozen. > >-- >Prasanna., > >On Mon, Jun 03, 2013 at 05:33:10PM -0400, Sebastien Goasguen wrote: >> -0 [binding] >> >> I am torn between sticking to the schedule and delay to make sure we >>can merge things cleanly. >> Would rather not merge and release on-time, but it would be a pitty. >> >> On Jun 3, 2013, at 5:09 PM, Kevin Kluge <kevin.kl...@citrix.com> wrote: >> >> > +1 [ binding ] >> > >> > I've been concerned that releases every four months were too >> > aggressive for people to absorb given the complexity of some >> > deployments and upgrades. With the current 4.1 delay and 4.2 plan >> > we would expect two major releases within two months of each >> > other. I'd prefer a bigger date shift for 4.2, but I see little >> > appetite for that in these discussions. So I will +1 this >> > proposal as a reasonable compromise. >> > >> > FWIW I doubt we'll get many more features in 4.2 with this. As >> > Animesh noted the feature proposal date has passed so we have an >> > upper bound on the additional changes for this four weeks. I >> > believe this proposal will improve the quality of 4.2 on its >> > planned release date as a result. >> > >> > -kevin >> > > >------------------------ >Powered by BigRock.com >
