On Sun, 4 Dec 2011 20:31:30 +0100 Cedric BAIL <cedric.b...@free.fr> wrote:
> 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" :-) It's tough to define something that's contextually abstract like that here. We could have a limit based on number of API calls introduced, but then someone could rewrite the internals and avoid such a rule, or vice versa. ------------------------------------------------------------------------------ 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
