Yes, to echo Joe, we welcome refactoring and refinements, burning down technical debt, etc. But for a project of this size (both in lines of code and number of community users/contributors/etc.), a formal issue tracking system is imperative. We do have existing tickets for generic refactoring of specific components (examples: [1][2]).
Any broken test should be resolved as soon as possible, and this should also be done under a new Jira (if discovered in the master build) or under the purview of the Jira where the broken test was introduced/existing test was broken. [1] https://issues.apache.org/jira/browse/NIFI-5462 <https://issues.apache.org/jira/browse/NIFI-5462> [2] https://issues.apache.org/jira/browse/NIFI-6356 <https://issues.apache.org/jira/browse/NIFI-6356> Andy LoPresto [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Jul 31, 2019, at 2:33 PM, Joe Witt <[email protected]> wrote: > > Understood. But we do need Jira tickets to cover, track, review changes. > > Thanks > > On Wed, Jul 31, 2019 at 4:42 PM Malthe <[email protected]> wrote: > >> I should perhaps have clarified, what I mean by refactoring is that >> code semantics are unchanged. If the road to contribution is one >> squashed commit per ticket then contributing meaningful changes >> becomes difficult when working with code that was originally written >> for a legacy Java runtime. Ideally, I think small contributions such >> as cleaning up code, fixing breaking tests etc. might do well without >> the burden of tools such as JIRA. >> >> Thanks >> >> On Wed, 31 Jul 2019 at 18:53, Joe Witt <[email protected]> wrote: >>> >>> this is also useful. >>> >> https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme+and+API+Compatibility >>> >>> On Wed, Jul 31, 2019 at 2:51 PM Andy LoPresto <[email protected]> >> wrote: >>> >>>> I’d suggest it’s the same as the process around any other issue. >> Identify >>>> a need (as you’ve done below), open a ticket for it, and contribute if >> you >>>> have the capabilities and time. If you need more discussion or >> direction, >>>> the mailing list is the right place for that. Once you have a PR, >> solicit >>>> reviews from committers, especially those in the git blame for the >> areas >>>> you’re modifying. >>>> >>>> I think if you’re looking for consensus or larger discussion, you >> should >>>> ask particular questions or outline the expected use cases and the >> problems >>>> you’re encountering here. >>>> >>>> >>>> Andy LoPresto >>>> [email protected] >>>> [email protected] >>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 >>>> >>>>> On Jul 31, 2019, at 11:28 AM, Malthe <[email protected]> wrote: >>>>> >>>>> What's the policy or strategy towards refactoring code without having >>>>> too much encumbering process around it? >>>>> >>>>> For example, there is code in StandardProcessSession.java [1] that is >>>>> unpractical to work with without a refactoring (more reuse of shared >>>>> logic, essentially). This applies to methods such as `putAttribute`. >>>>> >>>>> Thanks >>>>> >>>>> [1] >>>> >> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/repository/StandardProcessSession.java >>>> >>>> >>
