On Sun, 4 Dec 2011, Vincent Torri wrote:
>> 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. and also having some scripts that makes most of the process the easiest possible 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
