uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Eckart de Castilho <eck...@ukp.informatik.tu-darmstadt.de>
Subject Re: Contributing uimaFIT to Apache UIMA
Date Tue, 05 Jun 2012 12:44:17 GMT
>> To summarize briefly what else we have discussed so far:
>> - Two software grants will be prepared for the initial contribution because uimaFIT
is the
>>  product of two institutions.
> Sounds good, though I don't understand the details.  Will they be
> grants for different parts of the code, or will both institutions
> grant the whole thing, so there will effectively be just one grant?

I had in mind that one software grant document is signed at the University
of Colorado and the other one here in Darmstadt, each covering all
contributions done by the respective institutions to uimaFIT. Together, they
from a full grant of all of uimaFIT.

>> - uimaFIT will maintain its own release cycle.
> I'd like to understand why this point is important to you.  It seems
> to me our goal should be an integration of uimaFIT with the rest of
> UIMA, so why this insistence on a separate release cycle?
> Just to be clear, there will be nothing keeping you from making as
> many releases as you like (other than the usual community back and
> forth).

DKPro Core and ClearTK are strong drivers behind uimaFIT and have their own
release cycles. If we run into issues or need a new feature in uimaFIT, we
would like to be able to resolve it in a timely manner, in particular if
releases of these products depend on it. It makes little sense to ask for
a full add-ons release every time.

Mind, that we did not and do not implement project-specific features or
specific hacks in uimaFIT, but it may well be that these projects are the
first ones that require a new general functionality. E.g. movements in 
DKPro Core, DKPro Lab and DKPro Spelling have driven forward the development
of the external resources code in uimaFIT and the DKPro projects were the
first to use this feature.

Likewise, if any other project requires a bug fix or new feature which
may only be available in SVN at the time, we would like to be able to 
react to that by making a new release without much delay.

>> There are some more details to resolve:
>> - What happens to the uimaFIT documentation currently in the Google Code wiki? It
would be
>>  most convenient if that could be moved to the UIMA wiki. I would like to avoid having
>>  migrate everything to DocBook.
> Personally, I see no problem with that.  There may be volunteers to port
> the docs to DocBook, but I doubt it ;-).  What I find important is that
> each release is associated with a certain level of the documentation.
> This is most easily achieved via svn.  So one possibility would be that
> documentation is developed on the wiki, and then an export is checked in
> to svn prior to a release.  I believe there are Apache projects that
> work under such a model.
> Note that the documentation carries copyright and a license as well.
> So we need to check if we need to restrict write access to people with
> an ICLA on file or something.  I guess that's a solvable problem.
> The documentation should be part of the code grant.

Thanks for pointing this out. 

-- Richard

Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab (UKP-TUD) 
FB 20 Computer Science Department      
Technische Universit├Ąt Darmstadt 
Hochschulstr. 10, D-64289 Darmstadt, Germany 
phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de

View raw message