On Fri, 29 Jul 2011 17:20:24 +0200 (CEST) Vincent Torri <vto...@univ-evry.fr> wrote:
> > > On Fri, 29 Jul 2011, Vincent Torri wrote: > > > > > > > On Sat, 30 Jul 2011, Carsten Haitzler (The Rasterman) wrote: > > > >> On Fri, 29 Jul 2011 06:57:33 +0200 (CEST) Vincent Torri > >> <vto...@univ-evry.fr> > >> said: > >> > >>>> Secondly, this code is disabled, so it shouldn't affect anything right > >>>> now. > >>>> As I understand, it's normal in EFL development to add code that is > >>>> disabled, debug it, then enable it later when it works. > >>> > >>> no. It's not normal at all. > >> > >> of course it is! i've been doing this for YEARS! adding new features that u > >> need to either compile-time enable or runtime enable to use/see. is not > >> ecore-xcb exactly that? what about all of the loaders fo eavs, or > >> engines... > >> or... i can go on. > > > > except for ecore_xcb (my code, before devilhorns' changes), the code was > > always functional and of good, or high quality. According to cedric, the > > code here will not work at all on some important cases. > > and I repeat what i told you on IRC : these changes are in the most > important part of the EFL : the main loop. Also, doing such critical > change, even if it is optional, **just before** a release (if I'm not > mistaken the release is for september) is just masochism (as people will > use it if it is in a release, even if it is optional) > > so again, I'm against that commit. Add it later if you want (you're the > maintianer, so you do what you want), but now, for such critical change, > it's not good at all. > > Vincent I'm normally gung ho about new features and all, but it does seem like we're cutting it close by sticking this in only a month or two before a possible release. If I recall (and I do since I have my mailbox open and flames are spewing out), I tried to add threadsafety to a few eina data types before 1.0. Despite having it functional and being 2-3 months before our eventual release, I bowed to the great wisdom of vtorri and reverted it. A similar situation happened with a match from Mike M. which optimized some main loop functionality by converting lists to inlists. On top of that, even if it's disabled by default this brings a radical shift in EFL's core philosophy. If we're going to implement it then it should be with general agreement (which is definitely not the case at present) and proper evaluations/benchmarks/etc which should NOT be rushed or ignored due to a pending release. -- Mike Blumenkrantz Zentific: Coding in binary since '10. ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
