On Mon, 31 Oct 2011 23:01:59 -0400 Youness Alaoui <[email protected]> said:
> > Maybe the reason why raster is doing all > > > the work and nobody works on that TODO is because this is an open source > > > project, so everyone works on it on their own free time, which means they > > > only do what they want, what motivates them. > > You forgot discomfitor and T_UNIX working (and having worked) on big > > tasks of the TODO. Then there are others fixing bugs which is also > > critical for release but not on the list. > > > I didn't "forget" about them. I simply honestly don't know who is active i pointed people to this in this thread and several times over the past few months: http://trac.enlightenment.org/e/wiki/Release it lists who is assigned which task and what is done or not done. > and how, I am still new here and haven't been following the internals too > much. I do agree that my statement may have been untrue and based on > hypothesis, but it was as a response to raster saying that he's doing > everything himself (unless I misread that too). i never said everything - i explicitly mentioned discomfitor and t_unix - it's all there on that page. i have been doing the lions share though. if its the todo list u have an issue with it - work on it to get it done. i already said that 3 of those could be done after alpha. > > If everyone wanted those > > > features, they would have finished working on them by now. > > > And I don't want a release to happen earlier, I want releases to be > > planned > > > and release dates to be set and work to be done to make it happen on > > time, > > > I don't want to have a todo list dictate when the release should happen, > > > and not knowing if it's in one week or one year. > > > > > For initial release it is better to define the set of features that we > > want to provide and make sure that those work imo, especially after > > ten years of development. After that is done I'm all for having > > release cycles. > > > > Thanks, quite honestly the first 'sane' response I've seen here so far > (from "the opposition") as you are giving an actual argument to the > immediate problem. I do agree with you on that, definitely a set of > features is needed for the initial release. I don't agree though on the > ones being listed in the todo as being blockers for the release. i guess the reason i don't discuss this is that this has been discussed before - many times. we can do more regular releases after e17 is out - but we have a high level to achieve for it to be credible. that's where i disagree with the "dump everything excepting fixing efm" and the strict dates - if we say "release dec 1" and between now and dec 1 no one does ANYTHING and e is full of bugs - do you think we must then release dec 1 - mountains of bugs or not? i do not believe in that. i believe that you do all the major things first and fix all the nasties and then near the end make decisions on the more obscure bugs/features that u can "live without" or "we can live with that bug as it really doesn't affects many people". but we are not at this point yet. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ RSA® Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
