I have been wondering where to answer on this email thread, but I think that the
first one kind of set the tone and trend for the rest and overall it is a very 
good
example of bad communication and expectation to say the least.

On May 26, 2018 11:55 PM, 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.

You have been doing open source work for how many years now ? How do you
expect anyone to deal with such a bug report ? There is no task where I could 
find
details about them. It is just a rambling with the expectation that everyone is 
seeing
the problem.

> this batch leaves efl in a far worse state than before.

Thanks. Getting rid of technical debt is underrated.

> 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.

I guess you didn't know we had people overriding efl_del and a lot of other 
hacks.
So as soon as you fix the lifecycle everything falls apart. Leaving two 
options. Having
one giant commit which doesn't explain anything or small one that explain the 
reasoning
of the change. Their might have been a few that could have maybe not broken the
rest, but overall, with all the hacks we had in place, it was impossible until 
late in the
serie to make anything able to run.

> finding out the causes of these issues is nigh impossible. i've already spent
> over 4hrs on the above trying to find them.

Well, Marcel did seems to have find something quickly, I have no idea if that 
does fix
any other of your issues, as I obviously have not seen them nor gotten any way 
to
reproduce 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).

Seems a good advice along with not making a bug report.

> 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 don't know. What about T6879 ? It borked completely one of my computer and 
took
a month to get fixed. Would that have been corrected faster if I did write the 
same
kind of email as you did here ?

> 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. :(

The idea of associating drive by commit and branches is kind of interesting. 
The fact
are that many people did help on this branch and did tests it. There wasn't a 
way to
land a more atomically version of it (If you just read the commit message you 
will
understand how much technical debt there was that couldn't be dealt with small 
change).
Also your entire email and following thread is build on the assumption that I 
haven't
done any tests and just yolo landed 121 patches. Which is an absolutely 
ridiculous idea
that shouldn't even need to be discussed/debated, but well, I have run make 
check and 
updated/added tests as necessary. I have checked E and terminology on my laptop 
and
have been using it for more than a week before landing it. My branch has been 
buildable
and testable in public for weeks. I got people to run and check it. So at some 
point, you
might realize that not everyone, including you, has the same configuration and 
tests environment has limit that will only be caught when a larger population 
use it.

Anyway, this type of email are clearly not useful and tiring to deal with. It 
would be better to
come back to more constructive one. And I hope in the future to see better bugs 
report
and involvment with testing. Otherwise it is unlikely that any more important 
work that get
rid of our technical debt will take place and efl will just be on life support.

Cedric

------------------------------------------------------------------------------
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

Reply via email to