uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: Contributing uimaFIT to Apache UIMA
Date Thu, 31 May 2012 21:23:25 GMT



On 5/31/2012 4:02 PM, Richard Eckart de Castilho wrote:
> Hello,
>
> thank you for your feedback.
>
>>>> 1) uimaFIT already has an established user base.  This means it will
>>>> have backwards-compatibility requirements for that community.  This will
>>>> be a factor in how we proceed to integrate the concepts into UIMA.
> We (uimaFIT developers) would like a transition to Apache to cause minimal
> hassle for existing users. If possible, it should be limited to updating the
> imports for a new package name and changing a dependency/jar.

Yes, there's an expectation that the package names should start with 
org.apache.uima...

>
>>>> 1a) If we find, thru a bigger community discussion / involvement, other
>>>> directions we want to align the uimaFIT concepts with, it seems we might
>>>> end up with both an "old-style" uimaFIT - supporting the existing user
>>>> base, paying close attention to backwards compatibility and/or
>>>> migration, and a (likely incompatible) new-style integration of the
>>>> uimaFIT concepts into UIMA.
> We'd prefer uimaFIT to remain as-is for the transition. As has already been
> suggested and commented upon, some features of uimaFIT may eventually end
> up in the core UIMA framework. Currently I would think that this might be
> a new-style UIMA then. At this point, uimaFIT and UIMA should both continue
> to support a legacy code base for some time. However, it seems to me that
> this is looking to far into the future at the moment.
>
>>>> 2) Bringing the code for uimaFIT into the UIMA project: It seems it
>>>> would initially go into the Sandbox until IP issues (if any) are
>>>> resolved, and then be moved to the add-ons, since it is already a mature
>>>> thing with users.  If we then go down the path envisioned in 1a), we
>>>> would have some kind of parallel development in UIMA of the concepts.
>>> I don't understand the bit about the sandbox.  We'll need a code grant,
>>> which we'll only accept if we're satisfied there are no IP issues.  It
>>> won't go into subversion before then, and afterwards we can stick it
>>> wherever we want.  Right?
>> Yes, I guess I was thinking it might need some "work" before it was ready to get
"released".  If this work would complete before the next time we wanted to release all of
the add-ons (which, by the way, we might not do - we have the option of releasing just individual
pieces), then it could go directly into add-ons.
> Thank you for bringing this up. Assuming that we can satisfy your requirements
> regarding the IP clearance, it would be great if uimaFIT could go directly to
> the add-ons.
>
> Some work may be required to make a transition, but in general uimaFIT is
> extremely solid and has a very good test coverage.  From our side, are no
> reservations against making a new release any time soon. In fact, we have
> already cleaned up several things in the last few months with an upcoming
> contribution in mind.
>
> It would be appreciated if uimaFIT could continue with its own release cycle,
> that is, uimaFIT releases may be more frequent than UIMA SDK releases.

Yes, this should be possible.

>>>> Here's one example of a possible future alternative:  uimaFIT uses
>>>> special files to collect type system description references together
>>>> where they can be found by convention.  We have previously been looking
>>>> into various approaches to better manage issues around classpaths (we
>>>> currently have PEARs), based on OSGi support, including hooking up with
>>>> repositories (the idea being that UIMA components could live in Maven
>>>> repositories, and be "reusable" by reference, using the Maven schemes of
>>>> identifying artifacts by version).  A key part of this is the "version"
>>>> management.  As we go forward, we might find some interesting
>>>> integrations of type system information that is well aligned with these
>>>> kinds of conventions.
> [taking off uimaFIT hat, putting on DKPro Core hat]
>
> Type-system detection is a key element in reducing the boiler plate when working
> with UIMA using uimaFIT. The mechanism was first developed in the context of
> DKPro Core and contributed to uimaFIT because we (UKP Darmstadt) felt it was
> very basic and useful for other people to have. Currently, new mechanisms
> similar to you describe them above are being developed in the context of
> DKPro Core. We work towards another light-weight solution using Maven, but
> without OSGi. So far, we have not had real issues that require classloader
> isolation.
>
> [switching back to uimaFIT hat]
>
>>>> 3) If we "open up" the discussion around uimaFIT-inspired improvements
>>>> to UIMA, I can see pro/con arguments for moving uimaFIT to Apache:
>>>>
>>>> 3a1) Pro: It would require the IP "vetting" of the uimaFIT code base,
>>>> and thus make that code more re-usable inside UIMA.
> uimaFIT is already under the Apache License. I suppose after the IP clearance
> is through, parts could easily be integrated into core. Any advice as to IP
> problems that may crop up is appreciated.

We will need a software grant - see http://www.apache.org/licenses/ .

>>>> 3a2) Pro: It could likely lead to some new committers :-)
> Definitely. We do want to continue developing uimaFIT. The development of
> uimaFIT follows a certain spirit, that we want to maintain beyond the formal
> contribution. There is also a number of issues on our to do list. I suspect
> that it will mostly be me doing active coding. Recently, Philip and Steven
> do less coding, but still contribute with valuable comments.

New code bases come into Apache either via the Incubator, or via direct 
incorporation into existing top level projects, with an IP clearance done as it 
would be in the Incubator.

At the risk of saying what you may already know, the Incubator route is there to 
enable a sufficient community to form around the project - Apache doesn't want 
"orphaned" code with too few people able to commit to maintaining/developing 
it.  The Incubator also is there to enable mentoring of new people in the Apache 
Way.  (See
http://incubator.apache.org/ ).

We have had other code bases come into the UIMA project via a direct path (with 
a software grant, but not via the incubator).  In one of those cases, the people 
working on the code were already working on UIMA - so were part of the community 
and were knowledgeable in the Apache way of doing things.  In another case (I 
don't quite remember the details) - we had the software in UIMA and the 
contributor was contributing patches (he wasn't a committer) until we had some 
confidence he understood the Apache Way and would be a good team member.

Are any of the current people working on uimaFIT already Apache committers 
and/or familiar with the Apache Way?  If not, can others comment on the 
rationale for picking the incubator or "direct" paths?

Here's one comment - if there is only one active developer (at the moment) for 
uimaFIT, it would seem that to accept this other existing UIMA 
contributors/committers would need to agree to participate enough in uimaFIT so 
it had the minimal diverse community expected of Apache projects.   At this 
point, I'm interested enough to be one of the additional participants :-).

-Marshall

>>>> 3a3) Pro: It would likely result in increased focus/attention on making
>>>> progress in this area.
>>>>
>>>> 3b1) Con: It may confuse UIMA users somewhat, as to what we're doing.
> As long as uimaFIT remains a separate module, it should not confuse users too
> much. With a more official status, we expect and hope that more people will use
> and comment on uimaFIT and its concepts. Eventually, this should lead to a
> point that integrating its concepts into the core should cause little
> confusion amongts the users.
>
>>>> I guess this is all normal, and goes along under the category "managing
>>>> change" :-).
>>> Why don't we take this one step at a time?  First, a statement from the
>>> UIMA developers if they intend to accept this contribution.  I've heard
>>> no negative voices so far.  Second, the formal code grant and acceptance
>>> vote.  Third, a uimaFIT release as part of the next UIMA release.
> Please go ahead. We shall kick-off the IP clearance process once a formal
> vote in favor of the contribution has been made.
>
>>> That seems pretty straightforward to me.  When we have all that under
>>> our belts, we can start discussing if and how we want to move uimaFIT
>>> closer to the core.
> Mind that our intention not to hand uimaFIT off because we are done with it.
> We definitely intent that at least one of these "belts" you are talking about
> is around our waists.
>
> Best,
>
> -- Richard
>

Mime
View raw message