Hi, It makes me very sad to see how fast EFL work slips to the blame game when there is a problem. If the process is not working then focus on that not the person please. This was the result of a large amount of work that was required for the next release - if folk worked together to deliver these larger improvements then perhaps it would seem less personal when something does not go smoothly.
I hope that people are familiar with the concept "Judge Ourselves by Our Ideals and Other People by Their Acts" - that seems to be visible in this thread. If it looks like tests would have failed then it must be not tested - whereas if it were ourselves then it must have been a config or environment issue... When reviewing code it is possible that we may miss something but when someone else does then they are not doing a good job? Can't we assume that people are working hard and trying to do a good job? Just like believe of ourselves... This reflects, I think, directly the experience with the ecore loop rewrite - it broke a lot of stuff when it was merged in, but through discussion and patching we resolved it. That was deemed to be necessary because the underlying assumptions were wrong or the old code hacky - does this not seem similar? Why can't everyone just get along? :( Andrew On Sun, 27 May 2018 at 09:56 Carsten Haitzler <ras...@rasterman.com> wrote: > i've been dreading updating e1fl for the past few days. the dread proved > founded. the short version: > > the batch below is pretty horrible. it leaves enlightenment glitching with > garbage windows after a desktop switch or a second or 2. it makes > enlightenment's restarts significantly slower (like from 1 second on this > machine to like 2-3) with more visual bi-products (screen with just > wallpaper > visible for 0.5-1sec). the batch is also essentially unbisectable. > > this batch leaves efl in a far worse state than before. > > the batch itself is horrible because of the unbisectability. i have tried > now > about 15 commits (i lost count as i ended up in text console unable to > write > notes where i was writing them) and out of them only 1 compiled and ran at > all > without major issues. the largest amount of these just left e crashing on > startup along with another group having edje_cc crash during compilation. > while > the crashes were gone by the end of the batch the above issues (short > version > above) remain. > > finding out the causes of these issues is nigh impossible. i've already > spent > over 4hrs on the above trying to find them. > > so... i've gone back to 0090384ef5ac9f9e939874a1bbf233298c9db930 which is > good/works. i'm sitting on this (and i suggest anyone else do the same for > now). > > i'm going to wait until my wednesday morning here in seoul. if the above > issues > are not fixed by then i have no choice but to revert every patch from > 36f8a70041a8a16249a07d5b7131d57a8a6ea95b to > 75bb7c049f05176aef635bddcfb320c306b196bf from cedric because tbh - this is > the > problem batch as described. it's not personal. it's the reality of the > situation. i have to do this because there is no way an efl release can go > out > with these in place in their current condition. this is 115 commits btw... > so > going over every single one to figure out what may or may not be involved > is > going to be a major time sink that i don't think can be done well other > than > maybe trim the start of this series and keep some of those. i might do so > in > the meantime. > > i'm a bit disappointed on the lack of testing of these. :( also this is a > perfect example of drive-by commit batches causing major issues which is > why i > keep pushing against branches or hoarding of commits because they lead to > this > again and again. it also reinforces my take that work needs to be done in > small > units and shared frequently and i am certain the more and more common > issues > efl etc. are having is a result of the change to branches and hoarding of > patches and dumping them in large numbers. review doesn't work because i > already reverted one patch earlier today that was reviewed that totally > broke > e. review obviously doesn't involve any testing and that is the most basic > thing to do. :( > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > Carsten Haitzler - ras...@rasterman.com > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- http://andywilliams.me http://ajwillia.ms ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
