Peter, This is just my preference so discussion is certainly open. But the way I see it we should not set the fix version on JIRAs unless they really should block a release without resolution or if due to some roadmap/planning/discussion it is a new feature/improvement that is tied to a release. Otherwise, for the many things which pop up throughout a given release cycle they should be avoided. That is to say the majority of the time we'd avoid fix versions until the act of merging a contribution which also means it has been reviewed.
>From the release management point of view: This approach helps greatly as until now it is has been really difficult and time consuming to pull together/close down a release as pretty much anyone can set these fix versions and make it appear as though the release is not ready when in reality it is perfectly releasable as-is but might miss out on some contribs that someone would like to see in the release but has as of yet not gotten the PR and/or review traction necessary. >From the contributor point of view: If someone makes a contribution they obviously want that code to end up in a release. But being an RTC community we need and want peer review before the code is submitted. Some contributions are frankly hard to get peer review on or simply take time for someone to volunteer to do. PRs which are difficult to test, lack testing, are related to systems or environments which are not easily replicated, etc.. are inherently harder to get peer review for. Also, the community has grown quite rapidly and sometimes the hygiene of a given PR isn't great. So our 'patch available' and 'open PR' count ticks up. We need reviews/feedback as much as we need contributions so it is important for folks that want those contributions in to build meritocracy as well in reviewing others contributions. This helps build a network of contributors/reviewers and improves the timeliness of reviews. Long story short here is that because at times PRs can sit too long sometimes people put a fix version on the JIRA so it acts as a sort of 'gating function' on the release. This I am saying is the practice that should not occur (given the thoughts above). We should instead take the issue of how to more effectively triage/review/provide feedback/and manage expectations for contributions so contributors don't feel like their stuff will just sit forever. Does that make sense and seem fair? Thanks Joe On Wed, Feb 22, 2017 at 2:39 PM, Peter Wicks (pwicks) <[email protected]> wrote: > Just for clarification, "We really need to avoid the practice of setting fix > versions without traction", would mean don't set a version number until after > we've submitted a PR? Until after the PR has been closed? Other? > > Thanks, > Peter > > -----Original Message----- > From: Joe Witt [mailto:[email protected]] > Sent: Wednesday, February 22, 2017 12:55 PM > To: [email protected] > Subject: Closing in on a NiFi 1.2.0 release? > > team, > > On the users lists we had an ask of when we are planning to cut a > 1.2.0 release. And someone else asked me recently off-list. > > There are 45 open JIRAs tagged to it as of now. > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20NIFI%20AND%20fixVersion%20%3D%201.2.0%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20key%20DESC > > I'd be favorable to going through and seeing if we can start the motions for > a 1.2.0 release and which are ones we can wait for and which we should have > in 1.2.0 for sure. > > Is there any reason folks can think of to hold off on a 1.2.0 release? > > A non trivial number of the JIRAs are for things which have or do not have > PRs but have no review traction. We really need to avoid the practice of > setting fix versions without traction on this as otherwise it holds up the > releases. > > Thanks > Joe
