On Tue, 13 Dec 2011 10:29:50 +0000 (GMT) SANJEEV BA <[email protected]> said:
> My vote is for git + gerrit. > I find it to be convenient over email reviews, in that, I can see the > complete code and get the context, rather than read the diff (+/-) format and > then look up the code. I am a bit biased here because I am used to gerrit. > For someone new to EFL, I believe gerrit is a big plus. well after a decade of reading unified diff's (the +/- things)... you get good at it :)... but gerrits commenting inline in the changes is nice - and everyone being able to look and see the comments and add more of their own in places would help us do group reviews better. > I have been using both automake and cmake on Linux. Not many problems with > either of them so far. I will follow the crowd on this one :) > > ------- Original Message ------- > Sender : Carsten Haitzler<[email protected]> > Date : Dec 13, 2011 19:02 (GMT+09:00) > Title : Re: [E-devel] new build tree for efl. > > On Tue, 13 Dec 2011 07:51:52 -0200 Gustavo Sverzut Barbieri > <[email protected]> said: > > > On Tuesday, December 13, 2011, Carsten Haitzler <[email protected]> > > wrote: > > > On Tue, 13 Dec 2011 07:13:45 -0200 Gustavo Sverzut Barbieri > > > <[email protected]> said: > > > > > >> +1 > > >> > > >> Could we also move to cmake? How about git? I can have people to help > > with > > > > > > cmake -> no. despite how much i may hate autofoo... it's here and works > > and is > > > a devil we and many know. git - not currently, later on after e17 and > > > elementary are out. i have a list of requirements for it to come it - like > > > gerrit integration is a big fat must. we must have "git-commits" list > > working, > > > have a bot monitoring e-devel for git patch emails that will push them to > > > gerrit for review if they come in. it must be integrated to trac, and > > frankly > > > our rev no stuff we have now is based on svn commit # and will break - so > > first > > > i think a merge into a single efl tree lets us have a single point to > > chznge/fix > > > this. > > > > Funny to see this gerrit et al here, it's a trending topic at profusion as > > well and many projects. I'm saying this forever, the tool (or lack of it) > > is not the problem if the developers are unchanged. I'm all for nice tools, > > but I doubt gerrit is of any help here. > > > > Our volume of patches is very low and unlike to change. Our usage of tools > > is very low and unlike to change (read trac). Keeping the reviews at Edevel > > is the best way at the moment, and it does scale nicely, check LKML for a > > proof of that. > > > > But the funny part is that it's a requirement to move to have tools we > > don't have now. There will also be changes to the workflow that are enough > > to justify the change... No need to block due tools :-( > > i want gerrit. if we are using git then gerrit is a must. i want it. our > existing managament infra has to work via git too - that means for example our > devs dir management. website - on commit updates automatically. all the other > things we have running need to work (doc generation etc.). do this after e17 > and elm are done. > > > > so first lets clean house before we do more releases - so releases CAN > > happen > > > much more easily. right now they only get harder and more work each time > > as > > > more libs get added. > > > > Sad but expected from you. If we have cmake in parallel and it works, what > > are the chances we get it as the official? > > not touching cmake. even your friend - lennart, advises against it. you aren't > going to quote him? :) seriously - cmake does introduce: > > the devil we don't know. i sure don't know it. i'd say most devs here don't. > totally new build system and now we can't make the move easy by re-using make > Makefile.am's and configure.ac/m4 snippets. this will just make things worse. > as cedric said - cross-compile issues with cmake, less portability, unknown > usability for win32/wince support, and a bigger barrier of entry. so explain > to me what the use of cmake is good for if it now has more build issues than > autofoo? let's not go change build systems that have done things like given us > 1 line distchecks for years and handled cross-compiling, destdir for packaging > and more for a long time. > > > >> both. We did the webkit EFL cmake in short time, can do for EFL as well. > > >> > > >> Thanks for taking this long due change! > > >> > > >> On Tuesday, December 13, 2011, Carsten Haitzler <[email protected]> > > >> wrote: > > >> > ok - this 10 gazillion separate libraries is just not managable. we are > > >> going > > >> > to make a single build and source tree for efl. that means core efl. > > that > > >> means > > >> > 1 configure script for all. 1 base makefile tree. something like: > > >> > > > >> > efl > > >> > efl/src > > >> > efl/src/evas/... > > >> > efl/src/eina/... > > >> > efl/src/edje/... > > >> > ... > > >> > > > >> > we will still produce multiple shared libs, but under 1 build tree. 1 > > >> source > > >> > tarball for it all. 1 configure script. 1 efl version. 1 doc tree. this > > >> will > > >> > cover core efl. right now that means: > > >> > > > >> > eina eet evas ecore embryo edje eeze efreet e_dbus evas_generic_loaders > > >> (evil - > > >> > only compiled if on win32/ce) > > >> > > > >> > later elementary will get added (eio, emotion too). > > >> > > > >> > this move won't happen immediately, so this is a warning to EVERYONE > > WITH > > >> > PENDING PATCHES AND SOURCE TREES DEPENDING ON OUR SVN HIERARCHY (e.g. > > >> people > > >> > with git clones of specific libraries)... your patches are about to get > > >> broken > > >> > badly and your git trees made ineffectual when it comes to merging in > > >> upstream > > >> > as we will totally redo our tree. > > >> > > > >> > some people will not like this. sorry. reality is that world is totally > > >> > confused by EFL. we spend immense effort trying to educate the world > > >> where all > > >> > it sees is "efl" not "evas + edje + ecore +...". the fact is we do > > >> releases as > > >> > if it were a single efl. we may as well start doing it that way. > > >> > > > >> > benefits: > > >> > > > >> > 1. massively reduced release workload. > > >> > 2. massively better documentation as it now will be a single document > > for > > >> all > > >> > of efl nicely cross-referenced between each actual lib > > >> > 3. guaranteed synchronized release so we don't have to fine-tune check > > the > > >> > "required versions of efl libs" > > >> > 4. an actual release that resembles what the world thinks of us. > > >> > 5. doesn't break any api or abi compatibility > > >> > 6. a chance to start again with a simple single clean configure.ac and > > >> remove > > >> > many of the myriad of options in efl that just cause problems and have > > >> little > > >> > value > > >> > 7. makes much more sense to have a single tree when using something > > like > > >> git as > > >> > we either would have a single cit repo that just copies svn (possible > > but > > >> not > > >> > really using git properly) or we split into things like 1 git for e17, > > >> one for > > >> > core efl, one for "misc" etc. and so merging into a single efl tree > > makes > > >> sense > > >> > if we ever move to using git. > > >> > > > >> > -- > > >> > ------------- Codito, ergo sum - "I code, therefore I am" > > -------------- > > >> > The Rasterman (Carsten Haitzler) [email protected] > > >> > > > >> > > > >> > > > >> > > ------------------------------------------------------------------------------ > > >> > Systems Optimization Self Assessment > > >> > Improve efficiency and utilization of IT resources. Drive out cost and > > >> > improve service delivery. Take 5 minutes to use this Systems > > Optimization > > >> > Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ > > >> > _______________________________________________ > > >> > enlightenment-devel mailing list > > >> > [email protected] > > >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > >> > > > >> > > ------------------------------------------------------------------------------ > > >> Systems Optimization Self Assessment > > >> Improve efficiency and utilization of IT resour > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) [email protected] > > > ------------------------------------------------------------------------------ > Systems Optimization Self Assessment > Improve efficiency and utilization of IT resources. Drive out cost and > improve service delivery. Take 5 minutes to use this Systems Optimization > Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ > Systems Optimization Self Assessment > Improve efficiency and utilization of IT resources. Drive out cost and > improve service delivery. Take 5 minutes to use this Systems Optimization > Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
