Le 16/05/2011 16:19, Matt Benson a écrit :
On Sun, May 15, 2011 at 6:01 PM, Phil Steitz<phil.ste...@gmail.com> wrote:
On 5/15/11 9:43 AM, Luc Maisonobe wrote:
Le 15/05/2011 10:30, Mikkel Meyer Andersen a écrit :
+1
From me, too.
OK, it's done now. I have put everything as subpackages of
geometry as suggested by Phil, and I have taken care to use the
proper new exceptions as suggested by Gilles.
I could simply remove the bsp directory from sandbox now, but I
think it is a little more complicated, as we need to remove the
component from various lists (in the sandbox page, in Jira ...).
Whate is the proper procedure for this ?
There is no expectation that sandbox components will stay around.
Just svn rm it and edit the site (commons-site) to get rid of it.
IIRC, we don't have separate JIRA projects for sandbox components,
so there is nothing needed there.
You would also want to edit the svn:externals property that points to
bsp/trunk from trunks-sandbox .
Thanks, I think I have cleaned everything and deployed the updated
commons site. It should show up at next resync.
Luc
Matt
Phil
Luc
Den 14/05/2011 11.08 skrev "Luc Maisonobe"<luc.maison...@free.fr>:
Hello,
Some weeks ago, I have imported in the sandbox a new component,
Apache
Commons BSP which implements Binary Partitioning Trees (see the
thread
about this creation
here:<http://markmail.org/thread/mcg23trgtl472ica>).
Thinking further about it, I would like to directly merge it into
[math]. We are creating a new major release for [math], so it
may be a
good time to do so. Also as I changed the code to put it in
sandbox, in
fact I already did all the necessary work to have a working
implementation, with tests and clean reports from checkstyle and
findbugs. The implementation is complete for dimensions 1, 2 and
3 in
Cartesian space. I also need an implementation on spherical
geometry but
I can do that regardless of the component hosting this package.
So the
component could be promoted and it really makes sense to have it
inside
[math].
It could be put as a bsp package at top level (alongside with
geometry,
analysis, ode ...).
Does this suggestion makes sense ?
Luc
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
