On Wed, 22 Jun 2016 08:30:08 -0700, Gary Gregory wrote:
On Wed, Jun 22, 2016 at 7:19 AM, Gilles
<gil...@harfang.homelinux.org>
wrote:
On Wed, 22 Jun 2016 06:35:43 -0700, Ralph Goers wrote:
I agree with Benedikt. Plus, I have no idea who in Commons will
maintain this component since the “Math” guys say they con’t want
it.
I gave concrete (positive) arguments for having the components
submitted
to this vote (see other threads).
Could you please comment on why it would not be a good component?
It's absolutely not that the "Math guys don't want it".
It's that it would better for everybody (developers here and there,
users,
maintainers, release managers, you name it) to have independent
components
for independent and/or core/standard and stable functionality.
When I argued about having flexibility where needed (e.g. in
non-mature
"CM" code), the "stability" argument flag is raised to oppose it.
When I argue about enforcing stability (by consciously choosing the
"Commons" home), the "maintenance" is raised even though by
definition
of "stability", this is unlikely to be an actual problem.
Actually, the really problematic codes (those currently unsupported)
will
_all_ go to the TLP (for the PMC there to decide what to do).
What I propose as new components are the "easy" stuff, meaning
either
fairly easy to understand even by a newcomer, or easy to maintain
(lots
of unit tests; small, independent functions etc.).
This (and new components VOTE thread) paints a more confusing picture
than
before to me.
Please ask specific questions.
I can only guess, from repeatingly getting the same arguments despite
having answered them in all possible ways (and from different persons).
You are proposing to organize code into Commons Component/possible
TLP/Attic/Something based on the current knowledge of some
participants,
including yourself, and I am grateful that you've been doing all this
work.
Part of me wants to stay out of the way and let the do-o-cracy play
out but
another part really feels this will be counter productive in the end
(not
to mention a lot of busy work.)
My mileage does vary.
I've witnessed counter-production for 10 years now, boiling down to
what you say below: let's do nothing.
But who is "us"?
Right now, I'm proposing to do something together. And if you look
at the commit log, I'm the one doing something alone for the last 6
months. Or CM would have dormant already.
I'm OK setting up the new components, with the help of those who are
inclined to do so (that's at least 3 other people).
I'm just respectfully asking that people respect me (or what I did
here, or the fact that I'm still here), and stop blocking any and
all initiatives!
As was mentioned by someone else before, people come and go, with
different
levels of expertise.
If you want to imply that CM (and _all_ its code) would have survived
this long without Luc Maisonobe, I don't agree.
Luc was its biggest asset,
And, because of that, probably one of its liabilities (yes, I was
another
undoubtedly...).
For me, the keep-it-simple principle, not to mention least surprise
says to
keep whole the pile in one place, in Commons or as a TLP, either way.
Did I say that I do not want to manage a pile of cruft?
You want to keep a monolithic "Commons Math"?
How come that nobody asks how much effort it will be to maintain this
pile of ~100,000 lines of code, but one asks about the maintenance of
a tiny module of ~1,400 lines of code?
Even if no one else steps forward, I'm volunteering to maintain all 4
new components.
Because I trust that this will be _easy_, as much as I trust that CM
is unmanageable.
Whether we use more than one Maven module here or as a TLP is a
different
matter and not relevant to the residence of the code base. We have
other
Commons component that have multiple modules, no big deal.
That's beside the point, entirely.
The "maven" modules discussion is, I agree, to be left for the TLPMC.
The proposals we discuss now have nothing to with that TLP (except
to eventually narrow its scope).
Gilles
P.S. Isn't it telling that people who oppose do not say why the code
in question would not be a good component?
E.g. why is "crypto" a good component but not those I proposed?
Gary
Having those as components will accelerate the opportunity for wider
adoption (code is "production"-ready, modulo rather trivial
adjustments
to their new status), rather than having them wait until the TLP is
on
track.
Gilles
Ralph
On Jun 21, 2016, at 11:26 PM, Jochen Wiedmann
<jochen.wiedm...@gmail.com>
wrote:
-0
(I keep insisting, that we finish the organizational things first,
so
that CM can take such decisions without involving others. OTOH, I
won't stop you from doin that.)
On Tue, Jun 21, 2016 at 9:32 PM, Gilles
<gil...@harfang.homelinux.org>
wrote:
Hello.
This is one of several votes for establishing new Commons
components
out of functionality developed inside the "Commons Math"
component.
This vote is dedicated to the following functionality:
Representation of rational numbers
The concerned code is the contents of the following classes and
packages:
org.apache.commons.math4.fraction
located in the "develop" branch of Commons Math:
https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/fraction;h=446df46270ea0d00b7b23b603ca153df9ec18ffa;hb=refs/heads/develop
Notes:
* This component will depend on the "Standard math functions"
component
(cf. other VOTE thread).
* Code size: ~1400 lines of code (unit tests not included).
* API: stable.
* Estimated minimum Java version: 5 (?)
All are welcome to vote, especially potential users of the
candidate
component and people who'd like to contribute to it, through user
support,
bug-fixes and enhancements, documentation, release management.
[ ] +1, this would be a valid Commons component.
[ ] -1, this won't be a good Commons component because ...
Thanks,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
