On 01/12/2016 09:41 PM, Stefan Schmidt wrote: > 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. Does the elementary build take that long? can they not build then rm libelementary.so* and /usr/share/elementary/* like they need to do with other libs they don't require.
Having said that I don't care either way. Cheers Simon > >> 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
