Team, There was a lot of great progress yesterday, we closed or pushed 6 tickets. Also two tickets were added that are either critical or finishing shortly. The status of the remaining 12 tickets are below:
- "Corrupted flow file leads to a wedged flow" NIFI-2015[1] Added yesterday. Christopher McDermott, Mark Payne and Oleg Zhurakousky have been discussing the bug but no resolution yet. - "Allow user to specify file filter regex when unpacking zip/tar archives" NIFI-1568[2] [status] Matt Burgess is continuing to review - "Create PutSlack processor" NIFI-1578 [3] [status] Actively being worked on by contributor and reviewers - "Allow empty Content-Type in InvokeHTTP processor" NIFI-1620[4] [status] No change since yesterday, still waiting for final review by Adam Taft. Commented asking if Adam would like me to finish the review - "If unable to write to Content Repository, Process Session should automatically roll itself back" NIFI-1644[5] [status] No progress, commented asking Mark Payne (reporter) to see if it can slide. - "Misconfigured MonitorMemory ReportingTask can not be stopped" NIFI-1690[6] [status] Actively being worked on by contributor and reviewer - "Support Custom Properties in Expression Language" NIFI-1974[7] [status] New yesterday. Yolanda Davis submitted the PR and review by Mark Payne. Both are actively working on it. - "StandardProcessNode and AbstractConfiguredComponent duplicate instance variable "annotationData"" NIFI-2009[8] [status] +1 from committer, just waiting to be merged - "Create a processor to extract WAV file characteristics" NIFI-615[9] [status] No change since yesterday, I will review. Needs rebase though - "Add SNMP processors" NIFI-1537[10] [status] No significant change since yesterday, Oleg Zhurakousky is waiting for Pierre Villard to rebase. - "Add option to bulk using Index or Update to PutElasticsearch" NIFI-1594[11] [status] João Henrique Ferreira de Freitas addressed Matt Burgess' comments and is waiting for final review by Matt - "Create FlowDebugger processor" NIFI-1829[12] [status] Joe Skora added another commit and rebased. Tony won't be able to finalize review until the weekend, Michael Moser volunteered to finish [1] https://issues.apache.org/jira/browse/NIFI-2015 [2] https://issues.apache.org/jira/browse/NIFI-1568 [3] https://issues.apache.org/jira/browse/NIFI-1578 [4] https://issues.apache.org/jira/browse/NIFI-1620 [5] https://issues.apache.org/jira/browse/NIFI-1644 [6] https://issues.apache.org/jira/browse/NIFI-1690 [7] https://issues.apache.org/jira/browse/NIFI-1974 [8] https://issues.apache.org/jira/browse/NIFI-2009 [9] https://issues.apache.org/jira/browse/NIFI-615 [10] https://issues.apache.org/jira/browse/NIFI-1537 [11] https://issues.apache.org/jira/browse/NIFI-1594 [12] https://issues.apache.org/jira/browse/NIFI-1829 - - - - - - Joseph Percivall linkedin.com/in/Percivall e: joeperciv...@yahoo.com On Tuesday, June 14, 2016 7:11 PM, Andre <andre-li...@fucs.org> wrote: Tony, I second Joe's comments as well. Since the early discussions about the branching model I have been under the total impression that once 1.0 is released, 0.x would become support only and updates restricted to critical issues (security & data-loss break-fixes). This is not to say that a NPE or a 100% CPU issue shouldn't be backported, but I would imagine the effort to port to 0.x should be driven by the contributor rather than the merger (as it is being done atm). On Wed, Jun 15, 2016 at 8:13 AM, Joe Witt <joe.w...@gmail.com> wrote: > According to the discussion we had about the management of the release > lines there would only be incremental releases when something was critical > enough (security or data loss). And, if someone really wanted needed a > minor release they could initiate and do that as well. But as far as > continued feature development and focus it would shift to 1.0. > > So emphasis moves to new major line but those staying on the old major can > still have options as well. > On Jun 14, 2016 5:31 PM, "Tony Kurc" <trk...@gmail.com> wrote: > > Joe, for some reason, my mental image was that I expected we'd keep > releasing new 0.x minor releases for a while along with 1.x. > > Is that everyone else's expectations? >
