On 18/07/13 03:00, Cedric BAIL wrote: > On Thu, Jul 18, 2013 at 9:37 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: >> On Wed, 17 Jul 2013 15:10:45 +0100 Tom Hacohen <tom.haco...@samsung.com> >> said: >>> On 17/07/13 15:04, Stefan Schmidt wrote: >>>> On 07/17/2013 02:07 PM, Tom Hacohen wrote: >>>>> On 16/07/13 09:02, Cedric BAIL wrote: >>>>>> On Tue, Jul 16, 2013 at 4:35 PM, Stefan Schmidt <s.schm...@samsung.com> >>>>> wrote: >>>>>>> >>>>>>> Before the efl merge and the git move Daniel and myself played around >>>>>>> with what we already had in svn and made it work again. Should be >>>>>>> somewhere in SCRIPTS. >>>>>> >>>>>> If we can use coccinelle for that task it would be way better ! >>>>> >>>>> As I said, I'm not sure we can, as the changes are "weirder", converting >>>>> va_args to normal args. >>>> >>>> And instead of finding out by trying it you just want to drop the idea >>>> which is way better in line with what you planned anyway. :) >>> >>> That was the plan, but I'm willing to reconsider, as your points are valid. >> >> how about.. you take some sample snippets of existing eo api.. and try first >> and convert it? then you'll know. >> >> if we were back at our original eo start point and this was proposed - it'd >> be >> a very viable candidate. it has its downsides though (as i mentioned already) >> and upsides too. but the one BIG BIG BIG killer of eo2 is - time. to move to >> it, it would need to firstly be complete enough to replace current eo *AND* >> all >> existing eo api suers have to convert over. conversion is the nasty part and >> that will be by far the biggest time-sink. right now if we had to do it all >> by >> hand i smell several months of work here. if you can find an automated way to >> do maybe 90% of the conversion... or all of it even, then there is only >> "complete eo2" which frankly is enough work anyway. >> >> either way i am not willing to hold up efl 1.8 for this. if we change, we'd >> have to change AND then leave a few months of testing to check we didnt miss >> stuff/do it wrong... that assumes the change all happened today. >> >> eo2 seems nice... but your timing is pretty crappy :) > > I have been thinking the same to. I came to the conclusion that the > best things to do is to mark Eo.h API itself as beta and require user > of it to explicitly turn it on to use it. This means I think we can > just make it a not API/ABI supported library for the moment. > > This will give us enough time to handle a better API for it as it > seems eo2 is going into interesting proposal and it wont hold back 1.8 > for another semester. > > In general if we go to a time based release I guess this kind of > situation will happen much more often. So marking some API as beta and > not supported yet, seems reasonable to move forward.
I'm all in favour of that. That's what I wanted. -- Tom. ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
