I still see uimafit in sandbox, looks like it was copied instead of
moved? Ruta appears to have moved correctly.
-- Jens
On 11/25/2013 02:37 PM, Richard Eckart de Castilho wrote:
Let's wrap this up then ;)
uimaFIT has moved up (Updated: POM, UIMA website, Jenkins, Ohloh, README).
@DUCC: Do you have any opinions/plans on moving DUCC up?
Cheers,
-- Richard
On 22.11.2013, at 15:53, Marshall Schor <[email protected]> wrote:
+1 to moving uimaFIT and Ruta up one.
+0 to doing the same for DUCC - I suspect the community around that which is
very active trying to clean things up for an initial release, might not want to
rock the boat at this point... ?
--------------------
Looking at the uima-as/depend-on-parent-pom-4, the log shows this was copied
from the uima-as/trunk, and has never been updated since then. It is associated
with
https://issues.apache.org/jira/browse/UIMA-1830
which has the description: do this work in a branch until version 4 release [of
the build tools] is approved.
Based on this, I don't think this version serves any purpose, and unless someone
objects, I plan to delete it (of course, you can't delete anything from SVN, but
"deleting" it effectively hides it from most views).
-Marshall
On 11/22/2013 5:13 AM, Peter Klügl wrote:
On 22.11.2013 11:10, Richard Eckart de Castilho wrote:
I'm planning on moving uimaFIT one up.
@Peter: Will you do the same for Ruta?
Yes, I would do that if nobody objects ;-)
The ruta code is not as clean as uimaFIT, but the project is maybe
stable enough to leave the sandbox.
Peter
Even though DUCC is not yet released and stable, I'd vote for moving that up as
well. I do not think that there is much of a risk that DUCC will be stuck in a
low-quality sandbox level.
I believe these actions do not require a formal vote, do they?
-- Richard
On 22.11.2013, at 10:37, Jens Grivolla <[email protected]> wrote:
I was quite surprised by how things are organized when attempting to map the
SVN to git repositories. I would suggest to at least not have nested
repositories, so if you want to have sandbox/ruta, sandbox/uimafit, etc., I
would avoid to also have a trunk/branches/tags structure directly in sandbox.
I am also particularly confused by things such as
uima-as/depend-on-parent-pom-4, which is not a branch, not a tag, but also
isn't a separate repository with its own trunk/branches/tags structure like
ruta or uimafit. I'm guessing that it should be a branch of uima-as, but it
isn't.
Consistently adhering to the standard structure would make it clearer that this
is (probably) just a mistake, rather than some quirky layout decision.
I'm putting asking for the git mirror on hold until there's some decision
regarding the SVN layout (I don't care much about the result of that decision,
just that there is one).
-- Jens
On 11/19/2013 10:52 AM, Richard Eckart de Castilho wrote:
Hi,
I wonder if the current layout of the SVN makes sense as is,
in particular with respect to the sandbox and addons.
The addons and sandbox have always been released en-bloc.
Now we have Ruta, uimaFIT and DUCC, which all have their
own release cycles. However, they are still in sandbox and
break the "default SVN layout" with branches, tags, and
trunk there.
I believe there were also considerations of giving other
modules, e.g. every single add-ons module, its own release cycle.
I think that Ruta, uimaFIT and DUCC should be moved to the same
level as uimaj, uimacpp, and uima-as.
Any opinions?
Cheers,
-- Richard
