On Fri, 10 Apr 2009 11:46:08 -0300 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> said:
> On Fri, Apr 10, 2009 at 11:14 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Wed, 8 Apr 2009 12:29:50 -0300 Gustavo Sverzut Barbieri > > <barbi...@profusion.mobi> said: > > > > ok. looking here the problme is.. you have a schedule.. that has none of the > > following: > > > > a knowledge of how long tasks will take > > people available to do the tasks > > time guaranteed from all the people > > > > this schedule doesn't account for any of that. the result will be a date > > rolls around with none of the stuff done for it. > > > > i propose something MUCH simpler. if the aim is stability in stages maybe > > simply call freeze dates. > > > > "you have until 30th april to finish your current work, if it's underway. > > anything not done by then must be disabled/removed/unpatched. work can > > happen as long as it is compile-time enabled or runtime enabled and has no > > effect unless enabled". > > > > then within a few days of that date tarballs are produced with incremented > > release numbers. > > > > how about that? :) > > well, maybe i'm too bad at explaining stuff, but my suggestion was > exactly that. I don't want to block developers, that's why it is a well.. you did have a detailed release schedule on the wiki even a "e17 alpha - everything done" date :) > weekend. But it would be good to ask developers to help test and fix > bugs whenever possible. And I tried to put dates that would not bring > problems with GSoC since most developers are also mentors or students, > and also because it's good to know beforehand when it will happen. sure. > I already have my schedule in Google Calendar, I plan to mail the list > on Monday with a warning about freeze on Thursday, then one on > Thursday and then another on Sunday. Let's see how it goes. i would suggest much longer timeframes myself eg " april 30" then 1 weeks to verify everyrthing is stable and fix last minute things, april 7 - snap (announce a known svnrev that is with this snap - make dist the tarballs and upload). then next one may 30... and so on. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
