You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Malthe <mb...@gmail.com> on 2019/07/31 18:28:39 UTC
Refactoring
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
Re: Refactoring
Posted by Andy LoPresto <al...@apache.org>.
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
alopresto@apache.org
alopresto.apache@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> On Jul 31, 2019, at 2:33 PM, Joe Witt <jo...@gmail.com> wrote:
>
> Understood. But we do need Jira tickets to cover, track, review changes.
>
> Thanks
>
> On Wed, Jul 31, 2019 at 4:42 PM Malthe <mb...@gmail.com> 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 <jo...@gmail.com> 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 <al...@apache.org>
>> 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
>>>> alopresto@apache.org
>>>> alopresto.apache@gmail.com
>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>>>>
>>>>> On Jul 31, 2019, at 11:28 AM, Malthe <mb...@gmail.com> 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
>>>>
>>>>
>>
Re: Refactoring
Posted by Joe Witt <jo...@gmail.com>.
Understood. But we do need Jira tickets to cover, track, review changes.
Thanks
On Wed, Jul 31, 2019 at 4:42 PM Malthe <mb...@gmail.com> 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 <jo...@gmail.com> 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 <al...@apache.org>
> 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
> > > alopresto@apache.org
> > > alopresto.apache@gmail.com
> > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> > >
> > > > On Jul 31, 2019, at 11:28 AM, Malthe <mb...@gmail.com> 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
> > >
> > >
>
Re: Refactoring
Posted by Malthe <mb...@gmail.com>.
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 <jo...@gmail.com> 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 <al...@apache.org> 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
> > alopresto@apache.org
> > alopresto.apache@gmail.com
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> >
> > > On Jul 31, 2019, at 11:28 AM, Malthe <mb...@gmail.com> 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
> >
> >
Re: Refactoring
Posted by Joe Witt <jo...@gmail.com>.
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 <al...@apache.org> 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
> alopresto@apache.org
> alopresto.apache@gmail.com
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>
> > On Jul 31, 2019, at 11:28 AM, Malthe <mb...@gmail.com> 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
>
>
Re: Refactoring
Posted by Andy LoPresto <al...@apache.org>.
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
alopresto@apache.org
alopresto.apache@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> On Jul 31, 2019, at 11:28 AM, Malthe <mb...@gmail.com> 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