On Sat, 17 Dec 2011 05:30:31 -0500 Youness Alaoui <kakar...@kakaroto.homelinux.net> said:
> On Mon, Dec 12, 2011 at 10:15 PM, Carsten Haitzler > <ras...@rasterman.com>wrote: > > > On Sun, 4 Dec 2011 10:32:36 -0200 Gustavo Sverzut Barbieri > > <barbi...@profusion.mobi> said: > > > > > 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) > > > > > > 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. > > > > > > What do you think? > > > > i'm totally against timed releases. so lets sat 22nd of feb rolls around > > and we > > have added NO new features... we just do a release anyway? or 22nd of feb > > rolls > > around and a feature is in the middle of being ironed out? we release half > > done? we have to unpatch the feature because of a magic date? no. not to > > mention the unholy mass of work it is to release so many god forsaken > > libraries > > all at once. i've had enough of this multi-library tree thing. things are > > going > > to change come hell or high water. forget setting release dates until > > releases > > are more manageable. i'll send a new mail on this shortly. > > > I think everybody agrees though... > But I think that if 22nd of feb rolls over and there were no added > features, then you got a bigger problem with the project than the release > (it's dead!). As for a half-finished feature, if it's not finished by > freeze time, then it should be discarded until the next release (which is > fine since the next release shouldn't take too long to happen). > Anyways, the release management should be easier once the efl are all > merged into a single build tree, so that eliminates your other argument. Do > you have a plan/ETA for the single-tree change? Hopefully by feb 22nd? :) plan is to forget the rest of efl for now until we get elm1.0 and e17 out. after than we can worry about single tree then a new release. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
