Re: NiFi codebase warnings
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 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 > 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 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 > > > > 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
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 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 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 > > 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
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 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 > 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
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 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
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