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 >
