+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 >
