On Sun, 4 Dec 2011, Gustavo Sverzut Barbieri 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) > > 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 agree. But raster should not be always the release manager. So the first thing to do is writing a wiki page that list all the tasks to be done, in order for the release manager to not forget anything. Vincent ------------------------------------------------------------------------------ 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
