On 12/01/16 00:42, Cedric BAIL wrote: > Hello, > > As we are moving forward with a stable API for binding, one of the > main "weirdness" that is still exposed is that you need to actually > require two differents library to use efl. Also the only reason why we > haven't merged elementary so far as been because it still depend on > webkit-efl and webkit-efl depend on elementary. > > I am going to address that during next efl release cycle, by moving > the webkit dependency to be a module (like evas_generic_loaders and > emotion_generic_loaders). Once that is done it will be technically > possible to merge the both of them. > > This open a question, does anyone see any other reason to not merge > elementary ? > > If there is no other problem being seen to do this, there is a few > things that will be impacted : > - elementary developers branch can not be merged into an efl branch > automatically. Developers will have to either finish their patch > before we merge or have to take care themself of doing the move from > an elementary branch to an efl branch. > > - for the same reason, phab patch on elementary that won't have landed > before the merge will also be abandonned and their respective author > will have to move their patch on top of efl new merged tree. > > Due to the above effect, we should come with a clear timeline if and > when we do that merge to allow everyone to handle that big of a change > early enough to not loose time on patching the wrong piece of code. > Also I think this is going to impact efl 1.18 release cycle, and maybe > it should be adapted with maybe a technology preview in the middle of > the release cycle just after the merge ? > > Stefan what is your take on such a big change ? > > Cheers, >
As I already told you in private, let me know when, and I'll migrate the Git history. As for the patches/branches: it's actually not that hard, we just need to write a small script that maps previous file locations to new ones. This should work for everything, except for maybe Makefiles. I wonder if git (which already does file moving detection) can handle this gracefully when applying a patch. That is, doing something like: "apply this patch based on commit <HASH> and then follow the file moves until HEAD." I'm pretty sure this can be done with changing history, not sure about without. -- Tom. ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
