As someone who has surely been guilty of optimistically setting fix versions and then not meeting them, I second Joe's point about it holding up releases. Better to get the PR out, reviewed, and merged *before* setting the fix version in my opinion.
Andy LoPresto [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Feb 22, 2017, at 19:39, Joe Witt <[email protected]> wrote: > > 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
