On Sun, Dec 4, 2011 at 8:20 PM, Michael Blumenkrantz <michael.blumenkra...@gmail.com> wrote: > On Sun, 4 Dec 2011 20:15:07 +0100 > Cedric BAIL <cedric.b...@free.fr> wrote: >> On Sun, Dec 4, 2011 at 1:32 PM, Gustavo Sverzut Barbieri >> <barbi...@profusion.mobi> wrote: >> > Hi all, >> > >> > To avoid getting into the same situation as the current one, I'd like >> > to have a plan for the next release. >> > >> > I believe we should move to time-based releases such as kernel, >> > firefox and others do, making the life of distributions easier as >> > well. >> > >> > Freeze: 22-February >> > Alpha: 1-March >> > Beta: 8-March >> > Release: 15-March (guess, if no extra beta/alpha is required) >> >> I disagree on the timeline. I think we will not do anything worse a >> release so soon. To remember all, currently we are working on >> Elementary, Emotion, Ethumb and Eio to release them. This include a >> lot of API review/cleanup and documentation fix. We are also working >> on finishing the last few item on E17. All of this work will and could >> only depend on EFL 1.1, so not much improvement (mostly bug fixes) >> will go in svn until we are done with them. In my opinion, we should >> be able to produce an EFL 1.1.1 at the same time we release them, but >> it's clearly useless to me to schedule right now EFL 1.2 when all >> developper are working on something else. >> That's why we should for this EFL 1.2 just plan a 6 month release >> schedule, so be ready in may or june. > Unless I'm mistaken, the next item on the todo after EFL 1.1 was E17 1.0. > Finishing and working on other things should be put on hold. >> >> > It would be also great to define the policy of new features. With the >> > recent release we got some last-minute features to a codebase that was >> > very stable (multisense and lua for Edje), this added some turbulence >> > to the process and part of them were disabled at the end. >> > With that said, if you have big features please merge them >> > complete and at least somehow tested by more than you (ie: create a >> > branch, send patches to maillist, ...). Otherwise wait 4 weeks more >> > and you'll get it in! During this time you can easily keep the >> > aforementioned branch or patchset for broader test. >> >> The problem with branch and patches to the mailing list is that they >> don't get enough attention. Very few people do test them at all. So >> not really usefull. I would prefer to have a freeze period big enough >> to disable all feature that were added, but still push them in the >> main svn tree. And every one that push code in svn should accept the >> fact that it could get disabled at the time of the release if most dev >> feel it necessary. > This is true and reasonable. IMO for any "large" features, we should have a > policy of requiring at least several days of the patch existing on the mailing > list (3-4?). After this period, if there are no complaints voiced then it > should be assumed that either nobody has/will read it and can be committed.
I agree, we just need to define "large" :-) -- Cedric BAIL ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
