As Metron evolves to include new deployment options, features, and configurations it is hard and only getting harder for contributors, committers, and reviewers to understand what the required changes are across the different areas of the system to correctly and completely introduce a change or new feature in the system.
We have talked some about the requirements or expectations for submitters with regards to tests and coverage, coding style, and documentation but I don’t think we have enough guidance on deployment or other changes that need to be considered. For committers it is pretty much the same, with the extra stuff around that process. Right now it seems as a committer I’m counting on others like Nick or Casey to understand anything that may be missing from a submission when I review it. Should there by an Ambari/RPM change? Does this change the RestAPI? Does this effect STELLAR Lang/SHELL? Does it need customer Docker Compose work? etc etc. I think as we grow the community and try to get out of incubation it will be impractical for us to count on this, and we are even now increasing the risk of regression or functional gaps ( unrealized ) that will have an adverse effect on having a stable master. I think we should discuss if and how we can improve this or the issue of my sanity ;). What are the criteria that we need to have submitters and reviewers have in mind? * Test * Doc ** Obsoleting of existing documentation/how-to’s ( even hortonworks posts ) * Performance ** How do we test for performance? *** Standards *** Tools and processes * Deployment ** RPM ** Docker ** Ansible ** Ambari ** AWS Script * Functional ** STELLAR/Shell ** REST api’s * Dev/review guide ** Does the review / submit guide need to account for it? Any thoughts?
