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
