Obviously I think a lot of people agree with Mike's sentiments here. The community has been on a down turn for a while with excellent core developers leaving or becoming apathetic because of the lack of structure within the project which has led to quality issues, timeliness issues, and even interpersonal issues. There is a lack of userbase and development base outside of those who are paid to work on the project, and that is generally a sign of the project becoming so miserable to work on or use, that nobody is willing to do it unless they are compensated. Several of us made a last ditch big push to bring some structure into the project and address a lot of the problems that the project is facing -- this resulted in meetings occurring to try and develop some semblance of a project roadmap, releases, patch review guidelines, testing guidelines, and decision making process. We determined that a release of EFL was needed sooner rather than later, and that getting that release out would take a lot of work in a short time. Further we decided that some form of patch review would improve the project. We were unable to develop a plan for decision making other than we all can vote but Raster gets last say. Interestingly, in agreement with Mike, what I've seen following these decisions has been pretty bad. Cedric needed to land his work for us to start the release process -- while he was working his butt off to get there and get it ready, I saw Raster decide to go create a completely new module (bluez5) out of the blue, while plenty fixes and stabilizations were needed to get EFL even close to ready to release, or even while Cedric could have used help. When asked what the purpose of this was when other things were so pressing, Raster simply stated he thought his USB mouse used too much battery, and thus he wanted to use a Bluetooth mouse and using the command line interface to connect it was too much work. So, I mentioned to Raster that this patch set for the new bluez5 module (which uses frankly antiquated gadget api) meets the guidelines that even he agreed on to require patch review - I.E. It was greater than 50 lines, was a new feature unplanned for release, fell within an area of the codebase that others were familiar with, etc... Raster reluctantly agreed to put it up for review. Upon receiving critique in the review - Raster decided to desert the review process and just land the module into git master. Meanwhile there is a release process still trying to go on and work like Cedric's needing testing and review, and breaks within legacy api in EFL needing fixes for release. So to my amazement, with what appears to me to be poor leadership, I see all of Cedric's hardwork land followed by an email that absolutely blasts it and then blasts him while simultaneously somehow concluding that review processes don't work. There is a lot of hypocrisy here and a lot of double standards. Frankly if we want this project to move forward we have to stop treating it as a playground for some while requiring perfection from others. (When config was broken in E by Raster and I reverted it, I didn't come here to the list calling it horrible and making accusations about drive by changes and review not working). There are some of us who still have a lot of personal attachment to this project, as Mike mentioned, that are finding it harder and harder to watch the progression (or shall I say regression) of things. We have got to do better than this. We can do better than this. This project is better off for having Cedric and all of the work that he does and one patch set does not change any of that. We need to be far more professional as a team and exude a much better organization if we want users and developers and to see the project flourish. That needs to start from the top.
On Thu, May 31, 2018 at 8:01 AM Mike Blumenkrantz < michael.blumenkra...@gmail.com> wrote: > I've been struggling to find enough keyboard time to handle everything this > week, but this thread (and related discussions) have made me quite > discouraged in the meanwhile. There is far more time being spent using git > blame, and trying to blame people when problems arise in general, than > there is any form of collaboration or attempt to behave as a collaborative > community with a shared goal of making quality software. > This needs to stop; not only is it immature to throw a tantrum on the > mailing list whenever something breaks, it's also extremely damaging to the > morale of the project and its community members. While there have been > cries of "grow thicker skin!", I would argue that I have probably the > thickest skin of anyone in the project--figuratively speaking--but I still > don't think it's right to be making personal attacks on someone when their > code exhibits issues or if they are less knowledgeable about something. > There's a reason why the EFL contributor base and community have been > shrinking for many years, and it's not solely due to our lack of > documentation or coherent API. > > The issue(s) in question here (T6970) should have been reported and > discussed on the bug tracker first. An additional post should have been > made to this list to notify everyone that the issue had been discovered and > that updating was not advised--there was certainly no need for all these > pages of arguing and bashing Cedric for doing little more than exposing a > very longstanding issue related to gl image destruction (and a separate > minor issue which was quickly resolved by Marcel/bu5hm4n). > > As mentioned, the most recent issue was not Cedric's fault. This was one of > many longstanding issues that EFL has, waiting only for someone to uncover > it. The only method of triggering it is to destroy an image object which > reuses the same native surface which is actively being used by another > image: currently only reproducible with some optional features in > Enlightenment such as ibar/luncher popups and pager popups. If one of these > features was not in use, the issue would never trigger. > > If anything, this is a failure in our test infrastructure and coverage. Our > testing method should never be "build and run". What does this even mean? > If Enlightenment is being used as a valid test case for anything in EFL, > I'm of the opinion that our testing is woefully inadequate. Enlightenment > has hundreds of configuration options and a virtually unlimited number of > possible configuration options. What may be an "obvious" issue for one user > may never be seen by anyone else who uses it. Enlightenment should only be > a test case for Enlightenment code, nothing more. EFL needs to rely only on > its own testing to handle cases like this in the future. > > Lastly, while I agree that it's unfortunate there are so many unbisectable > patches in this series, that is still not a justification for a mail thread > such as this one. You claim to have been aware of the circumstances related > to Cedric's departure, but then you could easily have kept in closer > contact with him and known that he'd been updating a public branch for many > weeks with all his work--testable by anyone at any time. You could have > asked how the work was progressing, or if he needed/wanted any help. You > could have improved this process. > > Instead, what I can find of your public activity since the date of the > first patch in the series (4 April 2018) is: > * arguing extensively with me about a trivial build system patch ( > https://phab.enlightenment.org/D6013) > * arguing about and eventually rejecting patch review for your new bluez5 > enlightenment module (https://phab.enlightenment.org/D6148, related--still > no signs of progress on the e_gadget implementation) > * accidentally breaking freebsd module loading ( > > https://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg101770.html > ), > * rewriting part of the wizard module to fix freebsd module loading ( > > https://git.enlightenment.org/core/enlightenment.git/commit/?id=91463a9621de8b84caae90e9ab54d2ed43bd330b > ) > * arguing against patch review on the mailing list ( > > https://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg101789.html > , > > https://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg101734.html > ) > * arguing at great length in this thread > * resolving some longstanding efl bug tickets ( > https://phab.enlightenment.org/T6879, > https://phab.enlightenment.org/T6918, *others > which lack tickets totalling 36 patches*) > While this obviously shows that you've been quite busy over this time > period, it seems to me that there was likely enough time for you to have at > least talked briefly with Cedric about the large amount of pending patches > he had been developing to see if there was any way to help out, including > potentially testing the series before it was merged. I was also aware of > his timetable, which is why I did contribute both patches in the series as > well as testing and debugging for it. Others, such as the C# binding > contributors, were similarly involved. > > Since I've been involved with the project for a long time and still feel > some form of attachment to it beyond what I'm employed to have, I'll be > even more blunt in my closing even though I'm well aware that doing so will > be uncharacteristically unprofessional of me: > You consistently claim that you are the BDFL of EFL. In the past that may > have been accurate, but certainly I don't think that's the case anymore. > We've just lost one of our oldest, most dedicated, and most impactful core > developers--the second one in 6 months after JP; instead of trying to send > him off with a deep thanks and fond memories, you've created and > perpetuated this thread which reads to me (and to multiple impartial third > parties I've asked to review it) as little more than "go fuck yourself". > Where is the benevolence, the B of the BDFL? All I've seen here and lately > is a despot. > > > > On Wed, May 30, 2018 at 2:07 AM Carsten Haitzler <ras...@rasterman.com> > wrote: > > > On Tue, 29 May 2018 23:27:14 -0400 Cedric Bail <ced...@ddlm.me> said: > > > > > 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. > > > > what tone? that there is a problem and there needs to be a solution > > quickly for > > efl release? that i'm unhappy with the testing/qa for such large and > major > > changes? > > > > > 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. > > > > the e devel mailing list is expected to be subscribed to and read by all > > developers. you know this full well. so i expect "dealing with it" as > > reading the email like a human, some kind of response of "oh wait - don't > > revert > > it i can fix it" or "what? i tested it and it works perfectly for me? why > > does > > it break for you?". the details are in the email like they would be in > any > > ticket too. > > > > what about an email makes it impossible to be dealt with? i use emails > when > > there is more to be said than just point to a bug and track that, or for > > anything major which needs wider distribution (like don't update beyond > rev > > X, and that i think testing is not good enough). i would like to point > out > > that > > for example kernel developers exclusively use email for both review and > bug > > reports and discussion, so they obviously can deal with email... > > > > > > this batch leaves efl in a far worse state than before. > > > > > > Thanks. Getting rid of technical debt is underrated. > > > > before things worked and were faster on restart (well seemingly faster). > > after > > they do not work to a point where things are usable at all. and it's not > > just > > me seeing it too. others hit the same problems and started to send mails > > and > > pop up on irc... i do value the work behind it, but it's created a very > > visible > > problem just prior to an efl release. and just prior to you disappearing. > > > > http://www.enlightenment.org/ss/e-5b0e303f8d8576.82049191.jpg > > > > i described the issue in my mail. there is no backtrace to point to in > > detail > > nor could i even detail what commit broke it. > > > > i have since tried this on 4 systems, and the same result as above. > default > > theme, flat theme... single or multiple screens. intel or nvidia gpu. all > > 64bit > > arch though and all x11. > > > > > > 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 > > > > then as q66 said: it should have been merged, or divided so each commit > is > > "runnable" on its own. you have done open source long enough to know that > > introducing a large batch of "unbisectable" commits makes digging through > > history very hard. > > > > > 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. > > > > one way to do it: flag a class to have old or new style destroy and so > > object > > type by type they behave differently, cleaning up one at a time per > > commit. at > > the end remove flag feature as it's not needed anymore. an idea for doing > > it > > step by step. > > > > > > 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. > > > > no fix. i only know of: > > > > https://phab.enlightenment.org/D6222 - abandoned (doesn't fix) > > https://phab.enlightenment.org/D6223 - committed but doesn't fix it > > https://phab.enlightenment.org/D6224 - just adding test, not a "fix" > (but > > good) > > > > i'm looking at git master and i see no fixed in there and i don't know of > > any > > pending fixed... :/ > > > > > > 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. > > > > an email is both here a bug report and a broadcast for people to hold off > > on > > updating and where to stay to avoid problems - the mail detailed them. > it's > > pretty decent advice given people already hit the problem. > > > > i was hoping to at least get a "oh shit. really?" response. maybe a > "please > > don't revet - i think i know the source" or "it worked for me? why is it > > now > > broken for you and others?". instead i get this "well i did everything > > fine and > > it's the only way it can be done". > > > > this is the problem. you know full well you were quitting and going to > > vanish > > and just before that we end up with this commit. i was incredibly > > restrained > > and nice given the nature of what i have seen. since you sent a mail bout > > your > > sabbatical now, it's public knowledge but i knew it was coming and knew > it > > was > > end of this month and this lands right before the end of the month... if > > it was > > good without any major issues i wouldn't have said peep. > > > > > > 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 ? > > > > if you had reverted i would have understood. it didn't seem important at > > least > > to you due to the slowness of providing a backtrace and no other reports > i > > heard of. > > > > it's a code path that isn't common. it luckily was a single very small > > commit > > (not 100+). it took 3 weeks for you to provide a backtrace from original > > bug > > report (and i'd kind of forgotten about it due to reply gaps until i came > > back > > to it), then about 3 weeks or so until i read it again and saw the bt's > and > > saw what code path it might be and fixed it. my fix was within hours of > > seeing > > the replies. my bad that i added the bug. i did address it once i had > > enough > > info on what it might be (and noticed the response). > > > > > > 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 > > > > when there's a massive batch of commits going in and i know full well > that > > a > > few days after you plan to disappear... i do call this a drive-by commit. > > it's > > a worse version of "commit on friday at 5pm then go away for the > weekend". > > it's 100+ commits messing with deep internals a few days before > diappearing > > for a few months (and perhaps forever). call it a drive-by branch-landing > > if > > you want - the result is the same. massive amount of code delivered to > > master > > all at once with problems just before disappearing. > > > > indeed i do assume lack of testing because i have tried it now on 4 > systems > > machines. i know you have avoided testing e before and you directly > > admitted > > that, so i see results that indicate similar again. > > > > > 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 > > > > see above. edje_cc segv's in maybe a bit under half of the commits i > > landed on. > > e going into hangs and infinite loops inside destructor on maybe another > > 30% > > of them. i fail to fathom how it could have been tested when i ran into > > problem > > after problem. the infinite loops were in common code paths (destruction > of > > objects). if you have indeed tested it then i would dearly love to know > why > > everything is fine for you and seemingly not fine for quite a few others. > > > > > 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. > > > > that is true, but how can it be so bad when i look at it and all the > > commits > > inside and it work so wonderfully for you and others? edje_cc is not > > configuration related. perhaps race or libc mem layout related... but if > i > > got > > such reliable crashes how did things just all work a charm for you? > > > > > 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. > > > > i'll happily file a ticket if it needs tracking. one was filed within > like > > a few hours or so of the email anyway so not sure if there is a point: > > https://phab.enlightenment.org/D6220 > > > > i was not happy after many hours of building, rebuilding, rebuilding, > > resetting > > my bisect to a new range with new manually chosen commits to bypass the > "it > > doesn't even compile" problems so i don't know if the bisect is good or > > bad. > > > > let me put it this way. let's say you were a cook and the head chef walks > > in > > and notices part of the kitchen is on fire. he shouts "wtf? what is going > > on > > here? i'm running to get the extinguisher in a second if you don't put it > > out, > > and that'll ruin all food prepared for the day because of the fumes", and > > then > > your email here is "well it was necessary, but ... i was somewhere else > and > > didn't notice - also the other cooks were helping me out" ... do you > think > > that > > the chef isn't justified in yelling and jumping up and down? i didn't > even > > do > > that i actually was pretty calm about it. > > > > i made it clear in following mails that i valued the work and content. > > it's why > > i didn't just insta-revert. i know it's hard. but testing is not good > > enough. > > > > now i have since narrowed things down a bit. it only works with native > > surface/gl rendering. software is fine. i now am baffled how lifecycle > > changes > > affect a specific rendering engine or native surface path... but it does. > > this > > says to me that testing is indeed not good. not testing accelerated > > rendering/compositing in this day and age should have few if any excuses > at > > least on devices with such full support which is just about every > > development > > machine devs work on... > > > > > 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 > > > > > > > > > -- > > ------------- 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 > > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
