On Tue, 12 Jan 2016 22:00:59 +1030 Simon Lees <si...@simotek.net> said:
> > > 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. they certainly can. thus i don't see the point of making it optional. it simply affects build time and the very few who really don't want it can rm the build results (headers, .so's, modules, data/theme files, binaries). they are all clearly namespaced and trivial to remove. rm -rf $PREFIX/bin/elementary* $PREFIX/share/elementary $PREFIX/include/elementary* $PREFIX/lib/elementary $PREFIX/lib/libelementary* $PREFIX/share/applications/elementary* $PREFIX/share/icons/elementary* $PREFIX/lib/pkgconfig/elementary* put that in your build script after the make install. that's all. the extra build time is not that significant. and as i said - it's a niche need. i don't think we need to or even should have a --disable for this as disabling is solvable as above by the few who might want to. > 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 > > enlightenment-devel@lists.sourceforge.net > > 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 > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- 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
