You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by José Luis Pedrosa <jl...@gmail.com> on 2021/03/31 10:54:09 UTC
NiFi codebase warnings
Hi Devs/Maintainers
I've recently started using NiFi and I thought it would be a good idea to
give something back to the community while getting familiar with the
different areas of NiFi. I am writing to explain the relation between few
PRs that are submitted and check with you if it's a good idea and if it
would require a different approach.
I saw during compilation that are some warnings related to deprecated APIS,
that could be solved without a lot of issues, so I've submitted a PR for
each of the different APIs being deprecated, some of them internal, some of
them external, [1],[2],[3],[4].
I've also submitted an small PR regarding code inspections [5] (Make inner
classes static where possible). I guess after some more PRs all warnings
would be gone and it would be possible to enable warnings as error during
compilation.
So those are the questions that popped in my mind:
- Are these kind of initiatives wellcome?
- Should I handle it differently at code level?
- Should I do something different at Jira rather than creating
individual issues? (Maybe an epic level that comprises all of this?)
- Any particular improvement that sounds more urgent or you'd like to
get it done first?
Kind Regards
JL
[1] https://github.com/apache/nifi/pull/4947
[2] https://github.com/apache/nifi/pull/4945
[3] https://github.com/apache/nifi/pull/4942
[4] https://github.com/apache/nifi/pull/4941
[5] https://github.com/apache/nifi/pull/4940
Re: NiFi codebase warnings
Posted by Joe Witt <jo...@gmail.com>.
Please dont make that assumption. Lets read about these changes and why
they are good/help/etc.
On Fri, Apr 2, 2021 at 8:57 AM Mike Thomsen <mi...@gmail.com> wrote:
> I'll try to find some time to start looking at them.
>
> Since we're still building on Java 8, I assume a green light on the
> Java 8 build(s) means we don't have to validate that updated APIs are
> using Java 8-compatible ones.
>
> On Thu, Apr 1, 2021 at 2:16 PM José Luis Pedrosa <jl...@gmail.com>
> wrote:
> >
> > Hi Joe
> >
> > Understanding completely the situation, I see a lot of open PRs, and the
> > challenge reviewing them may present specially. I also understand the
> extra
> > care with PRs from non regular contributors. I'll keep only once open at
> a
> > time from now on. If you'd like that I create a set of Jira issues and
> > someone can assign them to me when there's bandwidth available to review,
> > that is also ok for me.
> > If there's any extra way I can facilitate the process, let me know.
> >
> > JL
> >
> >
> >
> > On Thu, Apr 1, 2021 at 6:13 PM Joe Witt <jo...@gmail.com> wrote:
> >
> > > Jose
> > >
> > > Thanks for your contributions and note. Such contributions and intent
> > > are welcome and appreciated.
> > >
> > > The challenge is our PR review bandwidth. We receive far more
> > > contributions than we have review bandwidth for. Four of your PRs
> > > touch a lot of files and the problem is if we don't get to them
> > > quickly your PR will get out of date/have merge conflicts. The energy
> > > to contribute is awesome and I dont want to deter you. I just want to
> > > recommend an approach to make it more enjoyable. Try to focus on a
> > > single PR at a time for instance. Once you build some momentum and
> > > folks in the community and doing reviews get more familiar with your
> > > work it can get easier too.
> > >
> > > Anyway just wanted to give a little perspective. What you have done
> > > is perfectly fine. Just sharing the challenge so many substantive PRs
> > > at once can present.
> > >
> > > Thanks
> > >
> > > On Wed, Mar 31, 2021 at 3:54 AM José Luis Pedrosa <jlpedrosa@gmail.com
> >
> > > wrote:
> > > >
> > > > Hi Devs/Maintainers
> > > >
> > > > I've recently started using NiFi and I thought it would be a good
> idea to
> > > > give something back to the community while getting familiar with the
> > > > different areas of NiFi. I am writing to explain the relation
> between few
> > > > PRs that are submitted and check with you if it's a good idea and if
> it
> > > > would require a different approach.
> > > >
> > > > I saw during compilation that are some warnings related to deprecated
> > > APIS,
> > > > that could be solved without a lot of issues, so I've submitted a PR
> for
> > > > each of the different APIs being deprecated, some of them internal,
> some
> > > of
> > > > them external, [1],[2],[3],[4].
> > > > I've also submitted an small PR regarding code inspections [5] (Make
> > > inner
> > > > classes static where possible). I guess after some more PRs all
> warnings
> > > > would be gone and it would be possible to enable warnings as error
> during
> > > > compilation.
> > > >
> > > > So those are the questions that popped in my mind:
> > > >
> > > > - Are these kind of initiatives wellcome?
> > > > - Should I handle it differently at code level?
> > > > - Should I do something different at Jira rather than creating
> > > > individual issues? (Maybe an epic level that comprises all of
> this?)
> > > > - Any particular improvement that sounds more urgent or you'd
> like to
> > > > get it done first?
> > > >
> > > >
> > > > Kind Regards
> > > > JL
> > > >
> > > > [1] https://github.com/apache/nifi/pull/4947
> > > > [2] https://github.com/apache/nifi/pull/4945
> > > > [3] https://github.com/apache/nifi/pull/4942
> > > > [4] https://github.com/apache/nifi/pull/4941
> > > > [5] https://github.com/apache/nifi/pull/4940
> > >
>
Re: NiFi codebase warnings
Posted by Mike Thomsen <mi...@gmail.com>.
I'll try to find some time to start looking at them.
Since we're still building on Java 8, I assume a green light on the
Java 8 build(s) means we don't have to validate that updated APIs are
using Java 8-compatible ones.
On Thu, Apr 1, 2021 at 2:16 PM José Luis Pedrosa <jl...@gmail.com> wrote:
>
> Hi Joe
>
> Understanding completely the situation, I see a lot of open PRs, and the
> challenge reviewing them may present specially. I also understand the extra
> care with PRs from non regular contributors. I'll keep only once open at a
> time from now on. If you'd like that I create a set of Jira issues and
> someone can assign them to me when there's bandwidth available to review,
> that is also ok for me.
> If there's any extra way I can facilitate the process, let me know.
>
> JL
>
>
>
> On Thu, Apr 1, 2021 at 6:13 PM Joe Witt <jo...@gmail.com> wrote:
>
> > Jose
> >
> > Thanks for your contributions and note. Such contributions and intent
> > are welcome and appreciated.
> >
> > The challenge is our PR review bandwidth. We receive far more
> > contributions than we have review bandwidth for. Four of your PRs
> > touch a lot of files and the problem is if we don't get to them
> > quickly your PR will get out of date/have merge conflicts. The energy
> > to contribute is awesome and I dont want to deter you. I just want to
> > recommend an approach to make it more enjoyable. Try to focus on a
> > single PR at a time for instance. Once you build some momentum and
> > folks in the community and doing reviews get more familiar with your
> > work it can get easier too.
> >
> > Anyway just wanted to give a little perspective. What you have done
> > is perfectly fine. Just sharing the challenge so many substantive PRs
> > at once can present.
> >
> > Thanks
> >
> > On Wed, Mar 31, 2021 at 3:54 AM José Luis Pedrosa <jl...@gmail.com>
> > wrote:
> > >
> > > Hi Devs/Maintainers
> > >
> > > I've recently started using NiFi and I thought it would be a good idea to
> > > give something back to the community while getting familiar with the
> > > different areas of NiFi. I am writing to explain the relation between few
> > > PRs that are submitted and check with you if it's a good idea and if it
> > > would require a different approach.
> > >
> > > I saw during compilation that are some warnings related to deprecated
> > APIS,
> > > that could be solved without a lot of issues, so I've submitted a PR for
> > > each of the different APIs being deprecated, some of them internal, some
> > of
> > > them external, [1],[2],[3],[4].
> > > I've also submitted an small PR regarding code inspections [5] (Make
> > inner
> > > classes static where possible). I guess after some more PRs all warnings
> > > would be gone and it would be possible to enable warnings as error during
> > > compilation.
> > >
> > > So those are the questions that popped in my mind:
> > >
> > > - Are these kind of initiatives wellcome?
> > > - Should I handle it differently at code level?
> > > - Should I do something different at Jira rather than creating
> > > individual issues? (Maybe an epic level that comprises all of this?)
> > > - Any particular improvement that sounds more urgent or you'd like to
> > > get it done first?
> > >
> > >
> > > Kind Regards
> > > JL
> > >
> > > [1] https://github.com/apache/nifi/pull/4947
> > > [2] https://github.com/apache/nifi/pull/4945
> > > [3] https://github.com/apache/nifi/pull/4942
> > > [4] https://github.com/apache/nifi/pull/4941
> > > [5] https://github.com/apache/nifi/pull/4940
> >
Re: NiFi codebase warnings
Posted by José Luis Pedrosa <jl...@gmail.com>.
Hi Joe
Understanding completely the situation, I see a lot of open PRs, and the
challenge reviewing them may present specially. I also understand the extra
care with PRs from non regular contributors. I'll keep only once open at a
time from now on. If you'd like that I create a set of Jira issues and
someone can assign them to me when there's bandwidth available to review,
that is also ok for me.
If there's any extra way I can facilitate the process, let me know.
JL
On Thu, Apr 1, 2021 at 6:13 PM Joe Witt <jo...@gmail.com> wrote:
> Jose
>
> Thanks for your contributions and note. Such contributions and intent
> are welcome and appreciated.
>
> The challenge is our PR review bandwidth. We receive far more
> contributions than we have review bandwidth for. Four of your PRs
> touch a lot of files and the problem is if we don't get to them
> quickly your PR will get out of date/have merge conflicts. The energy
> to contribute is awesome and I dont want to deter you. I just want to
> recommend an approach to make it more enjoyable. Try to focus on a
> single PR at a time for instance. Once you build some momentum and
> folks in the community and doing reviews get more familiar with your
> work it can get easier too.
>
> Anyway just wanted to give a little perspective. What you have done
> is perfectly fine. Just sharing the challenge so many substantive PRs
> at once can present.
>
> Thanks
>
> On Wed, Mar 31, 2021 at 3:54 AM José Luis Pedrosa <jl...@gmail.com>
> wrote:
> >
> > Hi Devs/Maintainers
> >
> > I've recently started using NiFi and I thought it would be a good idea to
> > give something back to the community while getting familiar with the
> > different areas of NiFi. I am writing to explain the relation between few
> > PRs that are submitted and check with you if it's a good idea and if it
> > would require a different approach.
> >
> > I saw during compilation that are some warnings related to deprecated
> APIS,
> > that could be solved without a lot of issues, so I've submitted a PR for
> > each of the different APIs being deprecated, some of them internal, some
> of
> > them external, [1],[2],[3],[4].
> > I've also submitted an small PR regarding code inspections [5] (Make
> inner
> > classes static where possible). I guess after some more PRs all warnings
> > would be gone and it would be possible to enable warnings as error during
> > compilation.
> >
> > So those are the questions that popped in my mind:
> >
> > - Are these kind of initiatives wellcome?
> > - Should I handle it differently at code level?
> > - Should I do something different at Jira rather than creating
> > individual issues? (Maybe an epic level that comprises all of this?)
> > - Any particular improvement that sounds more urgent or you'd like to
> > get it done first?
> >
> >
> > Kind Regards
> > JL
> >
> > [1] https://github.com/apache/nifi/pull/4947
> > [2] https://github.com/apache/nifi/pull/4945
> > [3] https://github.com/apache/nifi/pull/4942
> > [4] https://github.com/apache/nifi/pull/4941
> > [5] https://github.com/apache/nifi/pull/4940
>
Re: NiFi codebase warnings
Posted by Joe Witt <jo...@gmail.com>.
Jose
Thanks for your contributions and note. Such contributions and intent
are welcome and appreciated.
The challenge is our PR review bandwidth. We receive far more
contributions than we have review bandwidth for. Four of your PRs
touch a lot of files and the problem is if we don't get to them
quickly your PR will get out of date/have merge conflicts. The energy
to contribute is awesome and I dont want to deter you. I just want to
recommend an approach to make it more enjoyable. Try to focus on a
single PR at a time for instance. Once you build some momentum and
folks in the community and doing reviews get more familiar with your
work it can get easier too.
Anyway just wanted to give a little perspective. What you have done
is perfectly fine. Just sharing the challenge so many substantive PRs
at once can present.
Thanks
On Wed, Mar 31, 2021 at 3:54 AM José Luis Pedrosa <jl...@gmail.com> wrote:
>
> Hi Devs/Maintainers
>
> I've recently started using NiFi and I thought it would be a good idea to
> give something back to the community while getting familiar with the
> different areas of NiFi. I am writing to explain the relation between few
> PRs that are submitted and check with you if it's a good idea and if it
> would require a different approach.
>
> I saw during compilation that are some warnings related to deprecated APIS,
> that could be solved without a lot of issues, so I've submitted a PR for
> each of the different APIs being deprecated, some of them internal, some of
> them external, [1],[2],[3],[4].
> I've also submitted an small PR regarding code inspections [5] (Make inner
> classes static where possible). I guess after some more PRs all warnings
> would be gone and it would be possible to enable warnings as error during
> compilation.
>
> So those are the questions that popped in my mind:
>
> - Are these kind of initiatives wellcome?
> - Should I handle it differently at code level?
> - Should I do something different at Jira rather than creating
> individual issues? (Maybe an epic level that comprises all of this?)
> - Any particular improvement that sounds more urgent or you'd like to
> get it done first?
>
>
> Kind Regards
> JL
>
> [1] https://github.com/apache/nifi/pull/4947
> [2] https://github.com/apache/nifi/pull/4945
> [3] https://github.com/apache/nifi/pull/4942
> [4] https://github.com/apache/nifi/pull/4941
> [5] https://github.com/apache/nifi/pull/4940