Slightly off topic, but your statement "we need reviews/feedback as much as we need contributions" made me think that the project could somehow benefit from the concept of Kanban Work In Progress limits. Not sure how you'd implement this with an open source project, but just a thought.
On Thu, Feb 23, 2017 at 8:37 AM, Andy LoPresto <alopresto.apa...@gmail.com> wrote: > 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 > alopre...@apache.org > alopresto.apa...@gmail.com > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > > On Feb 22, 2017, at 19:39, Joe Witt <joe.w...@gmail.com> 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) < > pwi...@micron.com> 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:joe.w...@gmail.com] > >> Sent: Wednesday, February 22, 2017 12:55 PM > >> To: dev@nifi.apache.org > >> 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 > -- I know what it is to be in need, and I know what it is to have plenty. I have learned the secret of being content in any and every situation, whether well fed or hungry, whether living in plenty or in want. I can do all this through him who gives me strength. *-Philippians 4:12-13*
