uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thilo Goetz <twgo...@gmx.de>
Subject Re: Contributing uimaFIT to Apache UIMA
Date Tue, 05 Jun 2012 11:56:28 GMT
On 05/06/12 13:12, Richard Eckart de Castilho wrote:
>>> I think a contribution in form of an incubator projects makes most sense for
projects that later graduate to top level projects (like OpenNLP). Given the scope of uimaFIT,
a direct contribution seems more reasonably to me.
>>
>> I agree that the scope of uimaFIT implies a tight coupling to core UIMA, so it seems
less of a "subproject", and more of a core contribution.
> 
>>> I understand this is what has happened with the TextMarker project. It seems
to me that the direct way results is considerably less organizational overhead as well, e.g.
no need to set up a incubator project website and whatnot. There is some more overhead because
the protocol requires some time during which new contributors provide patches before being
given commit rights.
>>>
>>> A direct contribution could lead to a loss of identity to the uimaFIT project.
This is partially something that is desired, because we want to reassure users that uimaFIT
is becoming a part of the UIMA family and that using it is not "violating the UIMA way". It
would be appreciated though if some part of the identity could be maintained, e.g. by placing
the module at the same level as UIMA-AS. This would also make sense, as we would like to maintain
an independent release cycle.
>>
>> We have designed the add-ons to be releasable either all together or (more likely
going forward) as individual released things, so that's where I would suggest hosting the
original uimaFIT.  Over time, of course, I hope the goal is for it to be properly integrated
into the core.
> 
> Fair enough. 
> 
> So, how can we proceed? We uimaFIT folks started getting into initial contact with the
respective
> license persons at our institutions to resolve the software grant. These already mentioned
that they
> require the institutions to be mentioned somewhere. We assume that original authors and
institutions
> will be mentioned in the NOTICES file. Individual source files will carry the default
Apache
> license header which refers to the NOTICES file and will not carry author tags.

That can be done.  We have something in there for IBM right now, we
could do something along those lines.

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

> 
> - uimaFIT will be contributed as a patch at the level of add-ons. The patch contains
the
>   full uimaFIT as-is with packages, groupID and artifactIDs renamed e.g. to
>   "org.apache.uima.uimafit". This includes the submodules "uimaFIT", "uimaFIT Examples"
>   and "uimaFIT Spring". Any other changes would be submitted as patches afterwards.
> 
> - after the initial submission, I will contribute patches to uimaFIT via Jira as I plan
to
>   continue maintaining uimaFIT. In order to continue contributing, I will need to submit
a
>   CLA and ICLA. Patches are submitted until a full committer status is approved. Others
of
>   the original uimaFIT developers may choose to follow the same route at a later time.

> 
> - 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).

> 
> 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
to
>   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.

> 
> - What happens to the open uimaFIT issues in the Google Code tracker? I would suggest
to
>   open them in the Apache Jira, copy the initial description and link to the original
issue
>   on google code, as they might have a longer discussion history.

We can ask infra if there is a way to import issues from the Google code
tracker into jira.  If that's not possible or too much work, we can do
what you suggest.

> 
> Is there anything else that must be resolved or be made explicit that I did not mention?

The most important thing is that everything you want to bring to
Apache is covered by the code grant (see, e.g., the documentation).
Everything else can be worked out once the code is here.

> 
> -- Richard
> 


Mime
View raw message