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. 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.) As was mentioned by someone else before, people come and go, with different levels of expertise. 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. 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. 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 >>>> >>>> >>> >>> >>> -- >>> The next time you hear: "Don't reinvent the wheel!" >>> >>> >>> >>> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
