Alan: When will there be a really stable version of Magento2?

[andidhouse99]

Alan,

we put now over one year of effort into developing of magento2 sites. The first release was very "buggy" - and with every update you fixed only some bugs and more new bugs are introduced into the system. You can see this on every update - the bugs are not going to be any lower but keep rising and rising - and we are not talking about small stuff!

My simple question is here:

When will there be a version of magento2 which is ready for production without any major bugs?

Do not get me wrong here pls but we put over one year of effort into m2 now and still have no system at all we can go live with. We reported bugs confirmed by your team over 9 month ago where there is still no solution.

I think m2 has a very very big problem at the moment with its system - and i would simply like to know when you expect to be magento2 a system a normal agency / user etc. can use without putting more man hours into fixing bugs then into development.

We really get tired of putting most if the time into bug fixing here.

Simple question simple answer?

PS: I also do not really get this here. Some questions in this area are not answered for month? So you only are going to answer some questions here?

[Gabriel Guarino]

Hi @andidhouse99,

I've been working with Magento 2 for over a year now, and I don't agree with your comments at all. As any software, it gets better with every release, and the Magento team is there to hear your feedback if you are experiencing problems.

There are ways to communicate your concerns about Magento 2, and I don't think this is the right way.

If you have complaints about the response time for Github Issues or stability of the Magento releases, you can always find a way of communicating with the Magento team. Some examples:

• If you are really looking for a response from Alan Kent, you can send a Tweet to @akent99 in Twitter and I am sure that he will reply to your post on this Forum.

• You can always contact the Magento team by using the contact form in the website: https://magento.com/contact-us

To effectively report a problem, I suggest:

• If you opened Github Issues but you haven't received a timely response, make a list of those Github Issues
  
  
• If you had problems with the Magento releases, make a list of those specific problems to make sure the Magento team receives your feedback
  
  
• You mentioned major bugs in production, please create a separate list for those since they have higher priority

Finally, the Magento community is open and communicative, and we care about each other. If you report problems in an objective way, everyone will be there to help and guide you.

Best regards.
Gabriel

[akent99]

Regarding response rate of requests in this forum, some I do miss, some I simply don't know the answer to. The purpose of this area was for general direction / archtiectural questions (like your one). Some of the coding level issues I try to chase up internally sometimes, but I am frequently not the right person to ask. I frequently fire a message to someone internally in case they have time to respond, but this forum is not for issue escalation. I am across all the Magento product lines - I don't personally have the depth to know all the individual areas to answer all coding issues. But I have probably missed some I should have responded to. My apologies for that.

In terms of priority, Magento has been directing more resources at addressing issues rather than developing new features. 2.1.3 had ~90 issues addressed, 2.1.4 I believe already had ~60 queued up. Jason Woosley in his last internal staff meeting a few days ago repeated the commitment to "we are going to continue investing in addressing issues in what is already out there, with a lower priority on new features". We are giving priority to paying EE customers, but we are working on GitHub issues as well.

The other thing we are investing into is continuing to improve our internal practices to get things out more efficiently. Developers were not running the automated tests we did have as frequently as we liked due to how long they took to run, so we have been investing it getting the elapse time down (more parallel processing on more machines). Its not a complete solution, but its something we can do right now. Reducing the time between making code changes and identifying a issue improves our internal efficiency. Detecting issues late in the cycle adds unwanted delays as we have to back up and repeat phases of our internal deployment procedures.

I know the core engineering teams are also working on improving PR efficiency because I get invited to sprint demo meetings on automation to help speed up PR processing. We have to strike a balance between investing in tooling to improve throughput in the future and getting issues addressed.

If your issues are EE issues, please feel free to harass the Support team through the support portal. There is a dedicated team there who manage the escalation process of issues that the core team. We do give customers who pay and support Magento priority - CE would not exist without them. We are also working on CE issues however and are working through the backlog.

I am happy to forward on a list of GitHub issues for review, to make sure their priority has been set appropriately. They go through a triage process to set priority, but mistakes do happen.

[andidhouse99]

Hi all,

thanks first for your answers here. 

I like to point out again some things to make more clear what i mean. 

1. I am by far not the only one complaining about bugs. You can see Github here of course and the people here get more and more angry about the behaviour of magento. One example out of hundreds:

https://github.com/magento/magento2/issues/6335#issuecomment-270761983

Another one showing "simple things" are not fixed for month:

https://github.com/magento/magento2/issues/1691#issuecomment-270711563

2. If you read this post of a magento premium partner you get an idea of what is obviously going the wrong direction with magento:

http://webshopapps.com/blog/2017/01/what-magento-should-spend-some-of-that-250m-on/

3. All we as agencies and users of M2 ask for is a stable M2 version we can work with. At the moment it gets worse and worse with every release and as mentioned in the post the time for making promises is also over i think. Most of us put so much effort and money in M2 and now stand here with empty hands as most of the reported major bugs are not solved and new bugs keep floating in with every update.

Pls do not get me wrong here at all but i think it is turning the wrong way for magento at the moment. First premium partner begin to leave, not much M2 shops are online and also magento cuts the community for own profits... i am not really shure what the intention is of the company at the moment... all we ask for is a stable M2 system we can all work with... possible?

[whandy]

Gabriel Guarino I'm assuming your comment in regards to Magento 2 getting better with every release is directed toward EE, because 2.1.3 CE is not close to being stable. 

[MonkeyBear]

I don't think we will see a really stable version in a long time and I wouldn't be surprised if it never comes out.

The thing with Magento 2 is that I feel that they went the wrong route.What they should've done was simplifying Magento. Make it leaner, faster and easier to develop for. Remove stuff like those terrible XML files, fix the web APIs, simplify the DB structure, make the checkout easy to modify and add some speed improvements, because there is no excuse for pageloads that take seconds.

Instead of removing complexity, they decided to add even more code, frameworks and dependencies to an already overly complex system. The frontend is a disaster. You basically need to be skilled in HTML, PHP, Javascript, CSS, XML to customize the look and feel. Plus random new JS frameworks and libraries. Then you need to compile the code, manually clear some folders, probably compile again because it sometimes won't finish on the first pass. Then clear caches and maybe you will see some changes. I removed the wishlist button from the phtml because I don't need it. Just deleted the html tag, but now there were Javascript errors when you clicked on the add to cart button. My favorite sample is from the documentation:

http://devdocs.magento.com/guides/v2.0/howdoi/checkout/checkout_customize.html

In the <Magento_Checkout_module_dir>/view/frontend/layout/checkout_index_index.xml file, find the component that you need to customize. Copy the corresponding node and all parent nodes up to <argument>. There is no need to leave all the attributes and values of parente nodes, as you are not going to change them.
Change the path to the component’s .js file, template or any other property.
Example:
The Magento_Shipping module adds a component rendered as a link to the Shipping Policy info to the Shipping step:
<Magento_Shipping_module_dir>/view/frontend/layout/checkout_index_index.xml looks like following:

<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" layout="1column" xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd">
    <body>
        <referenceBlock name="checkout.root">
            <arguments>
                <argument name="jsLayout" xsi:type="array">
                    <item name="components" xsi:type="array">
                        <item name="checkout" xsi:type="array">
                            <item name="children" xsi:type="array">
                                <item name="steps" xsi:type="array">
                                    <item name="children" xsi:type="array">
                                        <item name="shipping-step" xsi:type="array">
                                            <item name="children" xsi:type="array">
                                                <item name="shippingAddress" xsi:type="array">
                                                    <item name="children" xsi:type="array">
                                                        <item name="before-shipping-method-form" xsi:type="array">
                                                            <item name="children" xsi:type="array">
                                                                <item name="shipping_policy" xsi:type="array">
                                                                    <item name="component" xsi:type="string">Magento_Shipping/js/view/checkout/shipping/shipping-policy</item>
                                                                </item>
                                                            </item>
                                                        </item>
                                                    </item>
                                                </item>
                                            </item>
                                        </item>
                                    </item>
                                </item>
                            </item>
                        </item>
                    </item>
                </argument>
            </arguments>
        </referenceBlock>
    </body>
</page>

All that for adding a link.

At other times, it's simply hard to tell if you as a developer made a mistake, or if it's another Magento bug.Because of the increased complexity, larger codebase and added abstraction layers it will probably also take longer to track down those bugs and for developers working for Magento to fix those. I also saw colleagues struggling with the concept of 
dependency injection and why it was better than the god Mage object. And maybe they're right, sometimes the most beautiful patterns go to waste if a product has to be used by the average joe developer who simply does not understand it. It's kinda like Wordpress. The architecture was terrible (just hack everything in the templates), but that's what made it a success. Most coders aren't geniuses.

If anything, Magento 2 should've made everything more easy. From the installation to theming, customization and developing extensions. Now it feels like a huge step back, especially with the bugs. I also think most developers who tried using M2 will just go back and wait a year before they try it again.

[andidhouse99]

Not really shure why bugs are reported on GitHub by the community any more. If you look at the release notes from 2.1.7:

"Magento 2.1.7 contains over 15 security enhancements as well as one significant functional enhancement. Look for the following highlights in this release"

1! bug is fixed and reported with over hundreds of bugs prooven and reported on GitHub....

[akent99]

Thanks for the note. Magento has two sorts of patches - bug release patches and security patches. Bug patches are for people to pick up if there is a bug fix they want. We consider them optional. Security patches on the other hand are strongly recommended for everyone to install, because as soon as they are released, they publicly share an exploit in the code. (Hackers will know about it as well.)

So you are correct the patch does not include bug fixes. It is on purpose. That 1 would have been 0 if the bug was not so serious.

And feel free to contribute any bug fixes you have time to work on. Magento is an open source project and we now have a dedicated team working on accepting pull requests that have got through most of the backlog. But the more people are able to contribute to open source, the faster the project can move along. So we are investing a lot these days into enabling the community to contribute more efficiently (including training sessions on how to most efficiently submit a fix.)

[andidhouse99]

Alan,

are you aware what is happening with magento2 at the moment? Nothing changed after creating this post here - i even got worse with bugs. 

Pls have a look at the updating problems of 2.1.8 at GitHub - magento2 is not usable as a solid ecommerce system and i am afraid that all that you and your team promised was not kept - it even gets worse when you have a look at the open Bug reports. 

[akent99]

Hi. I am truly sorry you are experiencing more problems. I don't know how to say that without it sounding cheesy.

Do we track and watch what is happening? We have deep metrics for EE - this is in our internal reporting all the way up to Mark Lavelle (our CEO). We track number of reported issues per patch released. So yes, we track this as closely as we can as an organisation. I can say with the global metrics (across the whole customer base) that each progressive patch release has had a lower reporting rate that previous patches. We continually look to increase the depth of these metrics for CE, but we the data is less reliable as traceability is harder (EE is easier to track dependably). 

That does not mean individuals don't experience more significant issues. Just using basic maths with a random distribution of issues, there will be some people experiencing more problems than others.

Are we happy with the number of issues reported? Not until its zero. Then we will be happy. This is why we are changing our internal organizational structure to dedicate more resources to support/defect fixing (L3 support). That has not fully kicked in yet - coming in the next month or so. We are also looking for 2.3 to allocate a significant percentage of core development resource to improving test automation coverage.

Does this mean M2 is more buggy that product X (including M1). I don't have the data on that. M1 did not have an open GitHub ticketing system with pull requests, a community engagement team etc. So its hard to compare to compare to M1. The relevant metrics compare defects per customer and per feature coverage (not absolute numbers). 

Is the ramp rate of defects on GitHub an indication of quality? Only if you can normalize it against the number of people using the code. As more people use it, of course there will be more reported problems. Because we don't see what all CE customers are doing, it is harder to get concrete data here.

What else is Magento doing? We have the community engineering team. We had community members providing bug fixes that were not being merged in. That is what they tackled first, and they have made huge improvements here as evident from the backlog size. Next, we want to equip the community better (the base product is open source after all) to submit fixes as well. Max and team have been holding community engineering days at numerous conferences to help community members learn how to submit requests so they can be accepted with minimal delay. On just this Monday we also annouced https://community.magento.com/t5/Magento-DevBlog/Magento-Partners-Contributions-Reward-Program/ba-p/... - a partner reward program (get credits for helping the community by fixing bugs rather than just reporting them).

To summarize:

• Do we care? Yes, we are investing a lot of resource into it.
• Are things getting better on average? Our cross whole community, stats indicate yes, each patch is getting better. We say this based on measured data. This feeds back into our internal resource allocation plans.
• Are we happy? No, not until its zero bugs reported. That dedication has increased and is going up shortly again as we complete the internal increase of the staff dedicated to such activities.
• Is the GitHub issue count an indication of quality? Somewhat - but it is also an indication of adoption. It is also an indication of commitment to transparency.
• Are we seeking community assistence? Yes! 2.1.8 had over 25 community pulls requests in it (browsing the release notes). We are geared up to getting them accepted faster, we are gearing the community up to submit them faster so they can be accepted on first submission.

So sorry you are experiencing more problems, but yes we are watching this area, all the way up to the CEO, closely. We take it seriously. We have been increasing our investment in this area and more is coming. And internal stats we monitor show the improvements.

But saying that does not take away the pain of the issues you hit personally, and does not excuse us from shipping code with bugs. We are committed to continuing to improve here.