Hello. On 12/01/16 01: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 ?
Nothing really from my side which would block it. We need to make sure having a --disable-elementary for people who do not want it as it is a rather big piece of code. What I consider as a must for the merge is to keep the git history elementary when merging it into the efl repo. Tom should have the knowledge how he and Daniel Willmann did it before with the other libs. > > 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. - Phab issues should just be batch moved from Elementary to EFL project once the merge is done. - I will update accordingly for Jenkins jobs as well as the release scripts and bits. > > 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 ? This will definitely not ft in our 3 months release scheme. We need some extra days before to make sure people have a chance to merge there existing branches, then some time to to prepare the repo, a hard freeze so the final merge can happen without interruption and a week or two stabilisation just to fix the fallout from the merge. My guts tell me that 4 extra weeks in our release schedule for the elm merge are needed as minimum. I'm fine with adapting the 1.18 schedule for it and we can come back to our well working 3 months schedule afterwards. This would move it from beginning of May to beginning of June. As for the actual merge plan I gladly leave this in your hands. Here are just some suggestions/ideas from my side. o After 1.17 is released we give people two weeks to get all the code merged that is sitting in branches right just waiting for the freeze to be over o After this window we hard freeze the efl and elm repos master branches for a week so you can work on the merge without interruption. People can still work in their dev branches during this time. o Once the merge is done we concentrate on making it work for all our scenarios for two weeks without new features being merged. o After that is done I'm happy to release a technical preview set of tarballs to give packagers and integrators an early idea what comes towards them. o After the technical preview is out I would go roughly into the 3 month schedule we had before. 2 months development, 1 months stabilisation. In a sense I would put the extra month for the merge just in front of our normal 1.18 schedule. regards Stefan Schmidt ------------------------------------------------------------------------------ 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
