On 14/01/16 01:52, Carsten Haitzler wrote: > On Wed, 13 Jan 2016 13:25:58 +0000 Tom Hacohen <t...@osg.samsung.com> said: > >> 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. > > wouldnt it just work to add an efl/elementary dir inside of which we import > the > entire git history of elm wholesale "as-is" and then from here git mv the > files > or dirs to new locations? >
That's exactly how it's going to be done (what we did for the EFL too). I was just wondering if there was a way to still cleanly and easily apply yet-to-be-applied-patches written for elementary.git to this new repo without my involvement. I.e just git am SOME_PATCH.patch. -- 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
