Thanks for being this up Andrew. I am also +1 for code cleanup. I agree that such efforts must hit the fork branches of each release line, thus: master, branch-2, branch1.
I’m -0 on taking such commits to release branches. These code lines are should be relatively static, only receiving bug fixes for their lifetime. Cleanup under src/test being a notable exception to this point. -n On Fri, Jan 10, 2020 at 13:08 Sean Busbey <[email protected]> wrote: > the link didn't work for me. here's another: > > https://s.apache.org/5yvfi > > Generally, I like this as an approach. I really value the clean up work, > but cleanup / bug fixes that don't make it into earlier release lines then > make my job as an RM who does backports more difficult especially when they > touch a lot of code. I know we have too many branches, but just handling > the major release lines means only 2 backports at the moment. > > I'd be happy with folks just noting a reason on the jira why something > couldn't go back to branch-2 or branch-1 (e.g. when something requires > JDK8). > > On Thu, Jan 9, 2020 at 2:12 PM Andrew Purtell <[email protected]> wrote: > > > Over on the Hadoop dev lists Eric Payne sent a great summary of > discussions > > that community has had on the tradeoffs involved with code cleanup > issues, > > and also provided an excellent set of recommendations. > > > > See the thread here: https://s.apache.org/fn5al > > > > I will include the top post below. I endorse it in its entirety as a > > starting point for discussion in our community as well. > > > > >>> > > There was some discussion on > > https://issues.apache.org/jira/browse/YARN-9052 > > about concerns surrounding the costs/benefits of code cleanup JIRAs. This > > email is to get the discussion going within a wider audience. > > > > The positive points for code cleanup JIRAs: > > - Clean up tech debt > > - Make code more readable > > - Make code more maintainable > > - Make code more performant > > > > The concerns regarding code cleanup JIRAs are as follows: > > - If the changes only go into trunk, then contributors and committers > > trying to > > backport to prior releases will have to create and test multiple patch > > versions. > > - Some have voiced concerns that code cleanup JIRAs may not be tested as > > thoroughly as features and bug fixes because functionality is not > > supposed to > > change. > > - Any patches awaiting review that are touching the same code will have > to > > be > > redone, re-tested, and re-reviewed. > > - JIRAs that are opened for code cleanup and not worked on right away > tend > > to > > clutter up the JIRA space. > > > > Here are my opinions: > > - Code changes of any kind force a non-trivial amount of overhead for > other > > developers. For code cleanup JIRAs, sometimes the usability, > > maintainability, > > and performance is worth the overhead. > > - Before opening any JIRA, please always consider whether or not the > added > > usability will outweigh the added pain you are causing other > developers. > > - If you believe the benefits outweigh the costs, please backport the > > changes > > yourself to all active lines. > > - Please don't run code analysis tools and then open many JIRAs that > > document > > those findings. That activity does not put any thought into this > > cost-benefit > > analysis. > > <<< > > > > My preference is to port all the way back to at least branch-1. Those > > interested in branch-1 maintenance and code lines derived from it, like > > 1.3, 1.4, 1.5, and soon 1.6, can decide what to do once it lands in > > branch-1, but we at least need the branch-1 backport as a starting point > > addressing some of the major prerequisites: Hadoop 2 support, Java 7 > source > > level, etc. > > > > -- > > Best regards, > > Andrew > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > decrepit hands > > - A23, Crosstalk > > >
