Thanks for your feedback, Lars and Greg. On the development process, all contributors/committers need to adhere to the process outlined by [1]. As mentioned in another thread regarding missing patches, we will immediately start monitoring and enforcing to get the process back on track.
It is true that upgrades have historically caused problems, and you are right that we need to step back and think about how we can do much better. I think that more design reviews, code reviews, and better execution of (and improving upon) the development process would go a long way as well as addressing technical debt, refactoring and re-archetecting where/when it makes sense. Contributors/committers, please chime in and share your thoughts on how we can make improvements to get to a much better spot in terms of improving stability, maintainability, reducing churn, etc. Regarding high numbers of JIRAs going into these releases, a large number of them are also attributed to Stack/common-service related changes. These changes tend to be smaller and specific based on what is needed by each service type on various deployment environments. Also, as 2.2.0 added a few large features, and thus it does stand out compared to 2.1.2 which was a maintenance release. Yusaku [1] https://docs.google.com/document/d/1hz7qjGKkNeckMibEs67ZmAa2kxjie0zkG6H_IiC2RgA/edit?pli=1 On 12/9/15, 8:45 AM, "Greg Hill" <[email protected]> wrote: >I mostly agree with what you're saying. I definitely don't want to kill >the velocity in Ambari, but it's impossible to keep up with the deluge of >JIRAs that get opened and fixed in each point release. 2.1.2 had 377 >JIRAs marked as Fixed, 2.2.0 has 719 (639 of those were marked as bugs). >Is Ambari just that buggy? Are the tests that insufficient? It seems >like we should maybe take a step back as a community and address the >problems that result in 639 bug fixes in a point release. That's >exceedingly high for a project of this size and scope. Maybe the velocity >of changes is creating more bugs than it's fixing? Are code reviews not >giving sufficient scrutiny to new contributions? Are there major >architectural problems that make bugs so common? I hope some of the core >developers on the project will chime in with their thoughts on how to move >things in a better direction, because frankly upgrading to 2.2.0 scares >me. We're on 2.1.1 and have worked around most of the bugs we've run >into. I don't want to find out what new bugs were created by the 1100 >JIRAs that have been closed in the meantime. > >I don't mean to call anyone out here. I just want to see things get >better. A new release of Ambari should be seamless. It shouldn't cause >panic. How can we fix it and how can we get the community involved in >making it better? As I say this I realize that I haven't contributed as >much as I've meant to. I'll work on fixing that. > >Greg > >On 12/9/15, 9:07 AM, "Lars Francke" <[email protected]> wrote: > >>Hi, >> >>sorry for yet another mail from a newcomer to the project. There's been a >>huge discussion (across a couple of threads actually) on the Incubator >>mailing list recently. It started with the "Concerning Sentry" thread[0]. >> >>The issue being discussed in that thread is that some feel that >>discussions >>and development actually happen outside of Apache and out of sight of >>other >>contributors. Having looked at Ambari for two days now I get a very >>similar >>feeling here and I would ask and urge you to look at your practices. >> >>Just to give some examples these tickets have been created, reviewed and >>resolved within the last three hours (most within minutes): AMBARI-14290, >>AMBARI-14288, AMBARI-14289. >> >>Two major and one critical issue. In my opinion waiting for at least 24 or >>48 hours before committing a patch would be good practice as would >>attaching a patch file to the issue itself as mentioned in my previous >>mail. Otherwise no potential contributor even has a chance to intervene or >>give feedback. >> >>Thanks for considering. >> >>Cheers, >>Lars >>[0] < >>http://thread.gmane.org/gmane.comp.apache.incubator.general/52126/focus=52 >>351 >>> >> >>PS: I sent this mail earlier from the wrong account but I don't think it >>ever made it to the mailing list, if it did please excuse the double post > >
