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? -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
