On Fri, 30 Sep 2016 10:45:47 -0500, Brent Worden 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.
Good.
Let's start solving problems, real or perceived.
Gilles
Brent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
