Re: [E-devel] Planning next Release of EFL

[Cedric B. <ced...@fr...>]

On Sun, Dec 4, 2011 at 8:20 PM, Michael Blumenkrantz
<mic...@gm...> wrote:
> On Sun, 4 Dec 2011 20:15:07 +0100
> Cedric BAIL <ced...@fr...> wrote:
>> On Sun, Dec 4, 2011 at 1:32 PM, Gustavo Sverzut Barbieri
>> <bar...@pr...> 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