Hi All, [Note my careful use of the terms "project", "component", and "module"]
Pardon my jumping in late... If some of this is leading to more than one commons-rng component within Apache Commons, I would be against that; Maven modules are a perfect match for this concept. Please allow me to relate my experience with Apache Log4j 2 where we have one project with 26 modules (granted there are 8 non-production modules: samples and benchmarks). For most releases, there are interesting and significant changes in only one module (log4j-core). A Log4j 2 release means a release of all modules and a guarantee that all modules work together (of course). Another example is Apache HttpComponets where there are several components and some components have several modules. This is not a trivial environment to set up as a project developer (unless I made a mess of my own personal set up, not unlikely! ;-) So far, Commons-RNG is a small and focused component related in theme to Commons-Math but these are not dependent on each other, so we have to keep that explanation clear. I would think that it would be better to have modules potentially come, morph, go, within one component. 3c, Gary On Fri, Sep 30, 2016 at 8:45 AM, Brent Worden <brent.wor...@gmail.com> wrote: > On Fri, Sep 30, 2016 at 10:02 AM, Gilles <gil...@harfang.homelinux.org> > wrote: > > > On Fri, 30 Sep 2016 09:41:44 +0200, Emmanuel Bourg wrote: > > > >> > >> - No immediate Jenkins feedback if a rng-core change breaks rng-utils > > > > > I'm not sure I got that one. > > If it means to copy the new "rng-core" over to some place for use > > by the build of "rng-utils", can't this be done by a "post-build" > > script? > > > The lack of immediate feedback is the same risk we have with other commons > components being dependencies of other projects, Apache or otherwise. I > think with the level that commons projects are policed through unit tests, > code reviews, backwards compatibility checks, and release candidate reviews > this risk is mitigated to a very acceptable level. > > In the past when the commons project changes did cause unintended upstream > problems, I feel we have done a good job reacting in a timely fashion to > address these issues and make process improvements if warranted. I do see > how we'd be any different, or need to be any different, with these two > components. > > If this is something we want more risk mitigation, we could set up both > components in Gump. > > > > > If that is not obvious to you, but are willing to trust other > > members here (me in this case), you could agree to make the > > experiment! :-) > > Then when we see more code, more users, more contributors, > > more opinions, and we see that there is merit in merging the > > two components, we'll just do it. > > [And I'll apologize to the INFRA people for the time they wasted > > in setting up the project.] > > > > > > Gilles > > > > > I was just thinking the same thing. Let's try one way and see it works to > satisfaction. If it does, great. If it proves to be burdensome or the > benefits are not realized, we can try another approach. > > Another thing I was thinking if we wanted to test drive the multi-project > route, what about setting up rng-utils in the sandbox? Process-wise it > would be a lot like a proper project thus, giving us the opportunity to see > how it would actually function. One benefit of using the sandbox is that > the work can begin immediately as it does not require infrastructure > changes. > > Brent > -- 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
