Hello. On 21/01/16 11:31, Stefan Schmidt wrote: > Hello. > > On 12/01/16 12:11, 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. >> >>> 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. >> > Where are we with this? if we want elm into efl for the next release we > need to think about how we are going to do this. I did not really get > feedback about my proposal here time wise as well as the steps involved.
I have not yet prepared a 1.18 schedule because I'm not seeing a real discussion or consensus on this. Where do we stand? 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
