Enyo 2.5.1 was it ready for release? (part 2)

Bugs, Bugs and more BUGS

4 bug tickets lodged in just over 2 weeks, 3 with corresponding forum posts. A couple of pages in my notebook of more bugs I don't have time to file because I'm too damn busy figuring out workarounds for them or hot monkey patching the framework. Of the 4, not a single one of them has been acknowledged on the ticket system as an actual bug. Only 1 of them has been replied to here by anyone from the Enyo team. I still have 1 forum post with questions about enyo.Source subkinds that nobody bothered to comment on at all for a month now. So much for the "In the meantime, we can answer any specific questions you may have in the forums" reply I got once.

I'm sensing some incredulity at my "couple of pages in my notebook". Here's one you can explore for yourself. enyo.Checkbox has setValue and getValue methods that proxy on to it's checked property. The API docs for the setValue method even state:
Whether or not the checkbox should be checked. The value will be treated as true if it is truthy; otherwise, false.
Ok this may have been valid before we had the 'new' style setters and getters but what happens when we use the 'new' style? Well let's see.
myCheckbox.set('value', 4);
myCheckbox.get('value'); // returns 4. huh?
Guess what doesn't happen though? You got it. The checkbox never gets checked. From the source:
* @private
valueChanged: function () {

* @private
// inherited behavior is to set "value" attribute and node-property
// which does not apply to checkbox (uses "checked") so
// we squelch the inherited method
Now I'm not saying that it should be fixed in this method necessarily, but does anyone else think that maybe, just maybe, we might have wanted to update this basic core control to behave as one might expect with the newer methods? Since virtually every binding you'll ever make to anything based off enyo.Input will be to it's value property. Just a thought.

While we're mucking around in the source let's notice that the setValue method states "The value will be treated as true if it is truthy". It uses enyo.isTrue. Let's take a look.
* Determines whether a given variable is an explicit boolean `true`.
* @param {*} it - The variable to be tested.
* @returns {Boolean} `true` if variable is an explicit `true`; otherwise,
* `false`.
* @public
enyo.isTrue = function (it) {
    return !(it === 'false' || it === false || it === 0 || it === null || it === undefined);
Pardon me. I just spit #$@&%*! coffee all over my monitor and keyboard. I'll refrain from inserting a link to any half assed online dictionary here for the word "explicit". For those at home though, the test for explicit boolean `true` is ... wait for it ... drum roll please ... it === true. Which is hardly what that function does. At least in Enyo 2.4.0 and earlier the comment read:
//* Returns true if the argument is true
Which is strictly the truth of the matter. Though it doesn't explain the exact operation of the function it is definitely much close than the description in 2.5.1.

Since we're on the subject of Basic Core Controls I want to mention enyo.Select. I had to lodge my second bug ticket against this yesterday. The reason I mention it: How does a unit tested framework like Enyo break one of it's basic user interaction pieces for almost a year and nobody notices? Where are the unit tests that should have prevented this? What the #$@&%*! was everyone doing?
Yes, pages in my notebook.
this.set('rant', 'off');


I waited patiently with baited breath along with many others for the release of Enyo 2.5. I new that the many of the features of 2.4 were being reworked and so I stayed with Enyo 2.2.0. That version was rock solid. I beat the living hell out Enyo 2.2.0. We have a distributed application in production for over 2 years now using that framework. It kicks all kinds of butt.

I expected that since it was announced to the world and all that jazz, I would be able to achieve similar if not even better things with 2.5 so I jumped right in. Now I'm buried up to my eyeballs in a new and complex project. Started it in a rather straight forward way: laying it all out, making the basic display pieces, etc... Then came the time to use what I came to this version for: Data Modeling, Bindings and so forth only to land in a world of pain.

Practically unusable API. Practically unreadable source comments (thank you jsdoc). A Developers Guide where most of the examples for the new features don't work at all because they are for a previous version. And broken basic core controls that used to be rock solid dependable.

Admittedly the pain is my fault. I didn't have time to fully evaluate the newest version and I made that fatal mistake of assuming that if it was going to be announced in the way that it was, that it was going to be production worthy. I spec'd out a project with untested technology. Those are my mistakes and I own them.

I appologize for any feelings that got hurt by this post. This was not my intent. I accept all responsibility for the views an opinions expressed here as they are 100% my own. I did wish to convey that though Enyo is open source and free there are those out there that do rely on the integrity, ability and reputation of projects of this nature and that rushing to release something before it's time affects others. That was my intent.


  • First, let me apologize for the slow response to your issues. One thing I have figured out is that the process for handling forum issues and external Jira tickets isn't as well handled as I thought. I will try to address this as we move forward so that there is a single point of contact responsible for handling it. I think we've been approaching this as a group effort and, when things get busy, we figure that someone else has it. Fortunately, this is an easy fix. I made sure all the bugs were already prioritized within our queue. I will try to be sure we communicate this better when a Jira comes in.

    Second, I want to tell you, by way of explanation, not excuse, that we're still largely driven by our internal priorities and pushing out public releases is a secondary (but important to us) process. We have quite a good set of procedures and tools around our internal releases but our public releases require a lot of manual testing.

    Third, the unit testing we have is largely focused on the data layer and other pieces of functionality that can be statically tested. The task that I've been working on for the last while is implementing automated UI testing and test coverage analysis. The unfortunate thing with the bugs you uncovered is that some of them are easy to miss with testing. The upside is that we can now add those failure cases to the automated testing to prevent regressions. The automated testing repo is available under the ui-tests repository on GitHub and integrates with Selenium (locally), SauceLabs (in the cloud) and, for our internal work, the TV. Unfortunately, I broke some of the tests with my recent work so I need to fix that.

    Fourth, as mentioned, we have already screened the bugs that you have entered. Resources requirements being what they are, they aren't going to be fixed until we have cleared up higher priority items. I encourage you to send me the other bugs you've found, even if you don't have time to write up formal Jiras for them. We can't fix what we don't know about.

    Finally, I want to say that our feelings aren't hurt. We understand and sympathize with you. We know you and a lot of other developers depend upon us to produce a solid product and we're unhappy when we fall short. We are looking towards our next public release and we will try even harder to make it better. The good news is that the next release is more incremental than the jump from 2.4 to 2.5 so there shouldn't be as much to cover.

  • From my experience in migrating, it wasn't fun.
    I don't think everything was ready for release when they released it. I also think they may have been a little pushed to make a release, since there had been a long time lapse since the previous release. (Well, not sooo long, but long enough the changes required a lot of effort to upgrade)

    I think there was a big failure in not release the migration docs up front, that had already been written. That should have been the top links in the release blog.

    Also, it wasn't nice to pretty much redo the entire data layer from 2.4 to 2.5, where there was such significant changes that i had to refactor a lot of my code. Not to say it wasn't for the better (though some things im still not sure of), but without that migration doc, i was left to fend for myself.

    I really like you opened up your docs to be edited, so i am sure it can only get better from here.

    I also miss unwiredben because he was the goto in the forums from any issue, and since he has moved on to better things, there is only a small presence from the enyo team it seems, instead of the everyday, or at the very least, every other day, that we had before.
  • Chris you are still building enyo apps?
    Nice! anything new?
  • Hi @chrisvanhooser, we miss Ben as well. :) We'll try to be more active on the forums - we've been heads-down working on some new stuff and would definitely like to check-in much more frequently and regularly. Thanks for your understanding and for your honest feedback about this latest release!
  • edited February 2015
    I think one of the big problems is that the jump from 2.4 to 2.5 took a very long time and from my perspective as an outsider it looks as though the 2.4-2.5 road was a combination of rewriting important parts of the applications as projects on their own, and incremental improvements driven primarily by the needs of internal projects on the side.

    Usually, incremental fixes are added in small increments, and major changes are split off to a larger update. Doing them all at the same time is risky and requires good internal organization and documentation of changes. It seems to me these changes have simply not been documented until a later time. If you don't document what you change, tests won't be updated and regressions won't get caught. Fixing this afterwards is a lot of work and more bugs will inevitably slip through the net.

    I'm happy to hear the next update will be more incremental and it is good to hear work is being done to streamline and organize things. I understand this takes a lot of time and effort for the enyo team, but in the long run it's vital to keeping a healthy active community.

    Keeping enyo in excellent shape is also our own responsibility as users of the framework. Open source projects live and breathe by the volunteered effort of their active users. So, for the sake of everyone using Enyo, I would suggest that, if you run into a bug and you understand it's cause sufficiently to be able to create a work-around or monkey-patch for your own project, please put in the extra 30 minutes it takes to create a pull-request. The more people do this, the better off the community is as a whole and long-term this pays off for everyone.

    As for important issues, I find if I am on the clock and I *really* need some input, helps to send an inbox message to someone from the enyo team. Aarontam has been especially helpful to me on several occasions, including putting time in over the weekend! To me, this shows the enyo team wants to do things right.

    Finally, even though I am not a member of the enyo team, I don't mind if anyone sends me an inbox message asking if I can look at a problem. If I can help out, I'd be more than happy to do so.
  • Oh, one other suggestion to the Enyo team specifically. If you receive a Jira issue or pull request and you are too busy to do something about it; Please write up a response anyways. Even if you are not able to act on it immediately in any meaningful way, the simple act of acknowledging a bug or pull request is much, much better than no reply at all.

    Also, if something an issue or pull-request takes more than an week to receive any meaningful attention, please give an estimate on whats going on. Worst case scenario the reply would be something like "thank you for your pull-request, we have added it to our queue but due to other more important issues it might take 3 more weeks for us to accept or reject it". It takes maybe 15 minutes during your morning coffee and it's so much better than silence.
  • Good feedback, Ruben. We've tried to go through all Jiras and respond to them.
  • Awesome, thanx Roy.
Sign In or Register to comment.