On Tue, Feb 2, 2016 at 8:24 AM, Stefan Schmidt <ste...@osg.samsung.com> wrote: > On 21/01/16 11:31, Stefan Schmidt wrote: >> On 12/01/16 12:11, Stefan Schmidt wrote: >>> On 12/01/16 01:42, Cedric BAIL wrote: >>>> 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?
I am more or less ok with this. Just we may have a travel planned at the end of February that may collide with the merging week you are proposing, but as I have no confirmation yet, I can neither confirm nor deny this planning. Other than that, I do agree with the general timing and planning for this release schedule. -- Cedric BAIL ------------------------------------------------------------------------------ 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
