[
https://issues.apache.org/jira/browse/ACCUMULO-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13684875#comment-13684875
]
Josh Elser commented on ACCUMULO-1488:
--------------------------------------
I tend to agree with [~kturner]'s initial view on this: we have no precedent
and the community has been split on this issue for quite some time.
Honestly, for something as seemingly standalone as this change, I tend to be on
the side of backporting the change. However, posting a patch on a
fixVersion=1.5.1 issue isn't the friendly way to approach this [~afuchs] as I'm
fairly sure you knew about this community split for quite some time (I could be
making it up that you weren't a part of any of the previous conversations on
the subject).
The problem as I see it is that the decision to backport a fix or feature is
currently subjective, which causes these arguments/discussions to repetitively
happen without making future decisions any easier. Additionally, this problem
*will* compound itself when we move to Git, as this won't simply be an issue of
"did someone `svn merge -r` the commit", but dorking with history itself. That
being said, I want to also note that I don't believe "I'll take on
maintenance.." is a statement that anyone can make in a community such as this.
95% of the time, your fix, as standalone as it is, won't affect anyone. That 5%
change when a different dev will run into a conflict, that dev is going to
resolve it on their own as this is the 1minute solution as opposed to 1+day
solution. Again, the difficulty isn't the issue, it's the principle of the
matter.
Sans major performance issues, Accumulo tends to get away with not having to
make many minor release versions which I think is a good thing. Up until 1.5,
we've had a rather pedantic release process and someone had to be guilted or
volun-told to handle the RC, testing, voting, deploying and promoting. As such,
my opinion would be to not backport things that aren't performance or
availability related. This opinion is also formed by users who are very
familiar with the dynamic classloaders (which tends to work _most_ of the time
even in production environments) and don't view `scp`'ing or `pdcp`'ing a new
jar out to the cluster as pedantic or problematic.
Then again, this is still all very subjective of me, and just prolongs the
larger issue as I see it.
> support BigDecimal encoding for basic built-in combiners
> --------------------------------------------------------
>
> Key: ACCUMULO-1488
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1488
> Project: Accumulo
> Issue Type: New Feature
> Reporter: Adam Fuchs
> Fix For: 1.5.1, 1.6.0
>
> Attachments: ACCUMULO-1488.patch
>
>
> Support sum, min, and max operations for decimal numbers using the
> java.math.BigDecimal String encoding and decoding functions
> (BigDecimal.toString() and BigDecimal(String)).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
