On Mon, 28 May 2018 19:55:55 +0200 Marcel Hollerbach <[email protected]> said:
> Hello, > > D6224, D6223, D6222 are fixing the issue. (Or at least the cases i have > seen). > > However, could you stop acting up like this & writing mails like this? > The lifetime of eo objects have been quite a mess, this branch brought a > bit light into the dark, it was not perfect how it came, sure, however it was far from perfect. every commit except 1 i tried was broken in blindingly obvious ways. not subtle breaks on unusual code paths, or more noisy ERR logs or something. it made it impossible to help out. if this were a single commit i might have revered it already due to the badness level of the results of it, but as it's 100+ it's going to be more involved and it's going to throw the baby out with the bathwater too. > here it is. Further more, you claim that this is not personal, why was > it then not enough to create a ticket, or simply a revert revision to > discuss things? Doing patches in EFL had always a team flavor for me, because i was giving cedric time to fix it. it was a notification of a pending revert coming if it isn't with a general publication so people know in advance why i did it (if it comes to pass) and have a chance to respond with "wait up..." or whatever. that doesn't belong in a ticket along with the below about the nature of the batch. do you think that things should be in tickets to "keep things hidden"? that seems to be what you are implying? i also wanted to point out in general the nature of the series that it's not bisectable and testing hasn't seemingly been done along the way (daniel pointed this out about squashing - i'm more about testing your commits and it'd be nicer to have smaller ones if possible than squashed big ones). others should not emulate this kind of development. should i bury this in a ticket so there isn't a public reminder to not copy it because of the problems it creates? > mails like this are destroying that feeling. So in the end: Could we > stop this stupid blame team and start to act as a team again? it's not blame. how else should i identify the patches in question? there were other patches at least in my git commits mailbox in between not from cedric (5-10 of them) and i hadn't checked if they were part of the push or not. it's not blame. it's identifying a problem set of patches that are not bisectable. if this wasn't about being a team, then i wouldn't have sunk most of my sunday into trying to find a fix for problems someone else created. i sent this mail as a last resort "i can't figure this out in any sane amount of time". i tried to even be clear that it wasn't personal, but you're forcing me to defend myself. it's about identifying the problem code. describing why it's a problem and offering an opportunity for the person who probably knows what might have caused the issue to address it in a timely fashion. how do you not identify them then to have this happen? there are also other reasons i will not mention here why i have sent the original mail and given a deadline of wednesday. also people in general needed a notification that git was now in a bad state and which revision last worked to go back to until this is cleared up. see irc logs and now emails on e-devel about this. i also do this in light of history. last year i called cedric out several times for breaking building against efl (early to middle of 2017). his answer was essentially "well i don't test a rebuild of e against efl changes because it takes too long". so he clearly stated he doesn't bother to test e before pushing. i asked him do this minimal testing... then i see this 100+ patch blob during which e simply doesn't work (except for 1 commit of those that i tried in bisecting), so it seems to me at least that testing e against this patch series wasn't done (a runtime test, not compile). i totally avoided bringing this up because i didn't want to start bringing up the past issues too, but when i see what are similar things again i'm going to point this issue out again. i don't want others taking the same shortcuts. IMHO i've done the right thing. it may make some people feel bad, but how else to identify a problem (see above)? i identified a problem (a series of patches from cedric from X to Y range as there is no other simple identifier, and the author needs to know to try and fix them), stated what the problems with them were (not bisectable, 2 adverse results, one of which makes e unusable for seemingly a wide range of people given the feedback streaming in over the past few days) and gave the opportunity to fix it before it holds up an efl release (i might have waited longer if that was not pending along with other reasons), with the only alternative being to revert the whole lot due to lack of bisectability as i don't see finding the issue any time soon as possible unless you have deeper insight into the work at hand. > Greetings, > bu5hm4n > > On 05/27/2018 06:39 PM, Carsten Haitzler (The Rasterman) wrote: > > On Sun, 27 May 2018 08:23:49 -0500 Stephen Houston <[email protected]> > > said: > > > >> Okay this is certainly not ideal, but try not to over react here calling > >> everything horrible and somehow deducing something crazy like not reviewing > >> patches is somehow better than reviewing patches. Let's give Cedric a > >> chance to clean it up. > > > > i spent hours bisecting and out of 15+ commits i tried to compile only 1 > > compiled and worked at all. a bit under a half didn't even compile. every > > other one led to e instantly segving on startup without even starting the > > compositor, e hanging in infinite loops in destructors within seconds of > > usage. i call it horrible because the batch is unbisectable. that means that > > the quality of the actual series is pretty bad as it seemingly was not > > tested due to so much of it not working in various ways. > > > > but don't worry. i'm giving cedric a chance to clean it up. why do you > > think i said i'm waiting until mid-week? it's going to probably take me a > > bit to revert all the patches too and maybe find conflicts, so i'm not > > going to go do that work if it isn't necessary. as of next friday i won't > > have time for about 2 weeks, so it's done by next thursday or not done for > > a long time. i did clearly explain that and since it's really hard to find > > the issues, if they aren't fixed quickly they have to be rolled back > > because it'll be probably months of broken efl until maybe it's eventually > > found. it may be weeks if we are lucky, but that kisses goodbye to the efl > > release schedule stefan has been informing us about. i don't want to go > > revert things because i find it fun. i do not. i do it because it's > > necessary. > > > > also today i have seen a string of people on email/irc complaining things > > are broken. this is seemingly incredibly common that it's broken. i would > > love to see it fixed, but i can't find out what in this mountain of 100+ > > commits did it as it's impossible to bisect. :( i spent the hours trying > > because my first port of call was to try and fix the issues first. so let's > > see if it gets fixed. > > > >> On Sun, May 27, 2018, 3:55 AM Carsten Haitzler <[email protected]> > >> 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 - [email protected] > >>> > >>> > >>> > >>> ------------------------------------------------------------------------------ > >>> 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 > >>> [email protected] > >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >>> > >> ------------------------------------------------------------------------------ > >> 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 > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > > > > > > ------------------------------------------------------------------------------ > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - [email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
