On Fri, Apr 10, 2009 at 11:46 AM, Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote: > 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 > 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. > > 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.
AH! And to prove my point and also the packager's point: quaker is trying to update the packages and Vincent just committed a massive change of ecore_*_free() to ecore_*_del(), almost at the same time. Changes like this are very likely to bring problems with missing renames here and there, problems with linkage and so on, so let's try to avoid doing them on the week we'll try to freeze. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ 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-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
