Hi Martin, On Aug 13, 2012, at 1:57 AM, Martin Desruisseaux wrote:
> Hello Chris > > Le 13/08/12 00:17, Mattmann, Chris A (388J) a écrit : >> d. Because of a-c), you should probably: >> - sign and submit an Apache Individual Contributor License Agreement >> (ICLA), as should anyone in the GeoTK community that comes over >> to Apache SIS, to cover your contributions here at the ASF. > > Yes, I will do and will ask other developers to do so too. Does Geomatys > needs to sign a Corporate CLA? Awesome, that will be great for the devs to sign ICLAs. If Geomatys is willing to sign a Corporate Contributor License Agreement (CCLA) that would also be nice from a provenance perspective too, and also to ease any of the devs from the company making Apache contributions. > > >> e. As an Apache SIS mentor, my question to you is: >> - do you anticipate closing down GeoTK at some point? If so, when. If >> not, why? > > We would like to transfer the code progressively to SIS, then replace the > moved Geotk code by a SIS dependency when the moved code has reached > equivalent functionalities. When all the code will have migrated, we can > close Geotk. However activities on Geotk is likely to continue until the > migration is completed. For example during the transfer of ISO 19115 > implementation to SIS, development of NetCDF bindings continue on Geotk. I > don't know how long the full transfer will take. Sure that makes sense, +1. > > We also have to manage the other projects that depend on Geotk > (Constellation-SDI, MapFaces, MD-Web, Puzzle...). Replacement of Geotk by SIS > will have to go through a "deprecate, then delete" cycle on the Geotk side > with some time left for allowing other projects to adapt. +1 > > >> Are others >> in the GeoTK community going to come over here to the ASF and Apache SIS >> project, or will work continue over at GeoTK? > > The plan is that others will come over SIS when the code to transfer will > reach the parts that they are involved in. If we transfer code in dependency > order, then this would probably means after the referencing module, when we > will start to talk about geometry, features and rendering. Until then, I > don't see any place other than Geotk where those developers could continue > their work... OK that makes sense. > > >> I would hope the answer is >> that work *would not* continue at GeoTK and that you guys would come >> here. It reduces friction, reduces duplication of development, and doesn't >> create issues of some code, or even replicated code over here at the ASF, >> being released and developed somewhere else (e.g., GeoTK.org). > > But the lack of branches can also, in some occasions, produce other kind of > frictions. Sure, internal branches are fine. It's just that at the ASF we don't want folks using our names e.g., "Apache" ProjectName (in this case Apache SIS), and/or our namespaces (org.apache.sis), and/or our code in competing efforts. It doesn't sound like GeoTK will be "competing" with Apache SIS since you guys have a solid plan for bringing the projects and the communities together, so just raising that. > Sometime a user or a company needs to apply a patch fast, because they have > some deadline required by contract. Sometime the patch is not acceptable for > a high-quality general purpose library - it may be too specific to particular > client needs for instance, or it may not fit well in the library design. Sure we have this issue with Apache OODT and so forth and we've had several projects and missions keep their internal modifications inside of their own local SVN repos and branches and such. Then, when the time comes, we hope that the members of those projects work on generalizing those branched functionalities and bringing them back to the benefit of everyone else (e.g., see OODT-215 [1] for an example of this). If they don't make sense to be brought back, then yes, they remain in the project repo. But I wouldn't consider this to be a competing effort, or any such, so I think that's fine. Also it's important to not splinter the community, and to have discussions on list and to make sure that all decisions related to the project happen here and not on internal mailing lists, or in those local branches/etc. No one's perfect, and we don't always get it right, but we try :) > Sometime the proper fix would require a much larger effort which can't be > afforded in the available time. Trying to push the patch in the SVN anyway > "because our client has paid for it" can also be a source of friction with > other members. +1 totally agree. That's why companies don't control the ASF, or its projects, and while we have a centralized board, it much favors local, decentralized decisions by the project management committee, and the project's community. Individuals, and their contributions, control the ASF and their projects. That's why it's a meritocracy here. Companies don't push us into committing patches :) Individuals push patches, when we trust them to give them PMC and committer access to the source code. So trust is important here, as-is the loose set of principles that we abide by called "the Apache way": http://www.apache.org/foundation/how-it-works.html > This is where distributed versionning like GIT can be a big help, since it > allows a company to maintain internally a repository clone with their own > patches until a proper fix is applied on the trunk. Heh, sure Git can do this, but so can SVN :) We've been doing it for years within several projects (Hadoop, Tika, OODT, etc.) > For those cases, the read-only GIT mirrors provided by Apache would do the > trick, since the "ugly" patches are not aimed to be merged back to the trunk. Sure, the Git mirrors are good for that, +1. Thanks man! Cheers, Chris [1] https://issues.apache.org/jira/browse/OODT-215 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
