hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@apache.org>
Subject Re: [DISCUSS] Guidelines for Code cleanup JIRAs
Date Fri, 10 Jan 2020 21:08:22 GMT
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 <apurtell@apache.org> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message