Right, I copied it, updated the jobs etc. but then forgot to delete the original. Done now :)
-- Richard On 26.11.2013, at 12:10, Jens Grivolla <[email protected]> wrote: > 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
