>> 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. 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. - 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. 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. - 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. Is there anything else that must be resolved or be made explicit that I did not mention? -- 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 [email protected] www.ukp.tu-darmstadt.de Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de -------------------------------------------------------------------
