All - Lars provided the Knox community with some feedback into our development practices and JIRA usage [1].
I wanted to bring up a DISCUSS thread on how our CTR policy may or may not relate to a couple points made in his feedback. In particular: 1. Whether a CTR based policy should require actual patches attached to every JIRA or does the git link to a commit provide the same ability to review post commit 2. Whether a cool off period of 24 hrs would encourage more external contributions and if so, how The incubator thread/s regarding Sentry's graduation was cited by Lars with regard to development process expectations and transparency [2]. Graduation criteria and evaluation seems to be a moving target in my opinion and the incubator certainly can define this criteria and individual members can use whatever assessment metrics that they like. I don't see these criteria and metrics as required for TLPs. That said, we should discuss whether we are "blocking" external contributions by our existing development process. @Lars, please feel free to describe how a cooling off period and required patch attachments in a CTR based project can encourage external contributions. While I personally don't currently see it, I respect your feedback as a contributor. My current opinion is that the CTR policy allows for the committing of patches without prior review as long as there is a means to get to the committed patch for review. The fact that git notification emails are sent to the dev@ list and linked in the related JIRA for every commit satisfies the requirement to easily get to the actual committed patch. Regarding the cool off period, I'm not sure that it adds any value to a CTR based process. To me this is a way to ensure a RTC policy. I do think that we as a community should be very clear about our definition of our development process and approach to CTR. To that end, we should update our contribution page to reflect this. We should also be adhering to the hybrid approach that I believe has been used within Knox. That being: * Changes, that are aligned with existing design patterns and Knox architecture, that are either incremental enhancements/features or bug fixes can be purely CTR * Changes that necessitate architectural changes, have significant security implications, or are generally large should be reviewed. This is to facilitate communication of such changes as well as to have another set of eyes for the code. * Architectural changes and completely new features should be communicated via the dev@ list and possibly within a wiki page for design discussion/communication. Let's try and ensure that a description such as the above is agreed upon and clearly documented in our contribution page and that we adhere to that definition. thanks, --larry [1] http://mail-archives.apache.org/mod_mbox/knox-dev/201512.mbox/%3CCAD-Ua_ibfetwjD2Mx1rOhXzc1y0h6b4PaXZThuByuRKp9oh29g%40mail.gmail.com%3E [2] http://thread.gmane.org/gmane.comp.apache.incubator.general/52126/focus=52351
