Hi Andrea, thanks for the insightful reply. Comments inline.
On Sat, 13 Feb 2021 at 10:27, Andrea Aime <[email protected]> wrote: > On Fri, Feb 12, 2021 at 5:09 PM Gabriel Roldan <[email protected]> > wrote: > >> Two courses of action have been mentioned previously: making a proposal >> (which I take as a GSIP), and that the parties involved fill in a "Software >> Grant and Corporate Contributor License Agreement" naming the project in >> order to donate it to OSGeo. >> > > A CLA is the minimum condition of a donation, indeed. > Communicated to the project manager. Waiting for definitive confirmation, I don't know if Camptocamp has signed a CLA already though. > A GSIP is the official way to propose and explain changes and large > additions to the project, so it could be a good fit, but I guess not a > requirement. > Settled then, I'll be creating a GSIP and pointing to the project's documentation. > > Proposals have originally been added to ensure there was a clear idea of > what to do, and all the necessary resources to actually do it. > If this is a one-off donation, the resourcing aspect is less important, > the CLA is however of paramount importance, to avoid having > another Stratus-like project bit-rotting around, that GeoServer core devs > cannot touch, in case an opportunity for reuse shows up. > My understanding is the project was intended to be donated to the community from its inception, and Camptocamp is going to keep using it with the current and other customers, which will provide funding and hence resourcing both for maintenance and continued development. The donation comes in the spirit that it'll be useful to other parties and in the hope of establishing a healthy relationship with the community, feeding on GeoServer, and contributing back to the upstream project. > > >> Given the project can't be put as a community module (technically it's a >> separate, spring-boot project, and conceptually it's not a GeoServer >> extension but a complete overhaul on its configuration and deployment >> mechanisms), the logical choice would be to host it as a sibling project at >> GeoServer's Github organization. >> > > Agreed. > Nice. > > >> So as for the proposal, I'm not sure a GSIP fits, although there're >> valuable components developed under this new project that could well be >> subject of GSIPs to make their way upstream, such as improvements in the >> design of the catalog/config subsystem, event-based synchronization, and >> Jackson-databind bindings for all Catalog and Config objects, including >> GeoTools Filters. >> > > Those should be subject to further GSIPs indeed, in case you want to > migrate those bits to the main project. > Yes, I'll start by splitting them into community modules where appropriate. There's a good chance of being able of reusing them, confining the spring-boot aspects (auto-configuration and the like) to this project. Took care that even the Catalog/Config improvements can start being community modules to ease the discussion and testing while/if they make their way to core. > > >> Yet, since there's probably no other prescribed process to support this >> sort of donation, at least to the best of my knowledge, we could probably >> abuse/extend the GSIP scope. What are the precedents in that regard? Has >> the landing of GeoFence as a sibling project gone through something similar? >> > > Good point, I could not find a proposal for it. GeoFence back at the time > gathered limited interest, we did not have much discussion about it. > I've found a mailing list thread: > https://sourceforge.net/p/geoserver/mailman/geoserver-devel/thread/1534616.ijsF6tZBgt%40saxicola/#msg32882096 > The thread also mentions a PSC meeting, but could not find the meeting > notes related to it. > > One important aspect of GeoFence is that it came as a packaged deal with > some dedicated people to move the project forward. > > What I would like to know is if the donation is a "one time drop" or it > comes with plans for the future from the original developers, > and if they are available for its maintenance in the short to medium term. > As mentioned above, not a one-time drop. For the immediate future, there's a commitment on maintenance and bug fixing, and for the medium term, there's the intention of further development. I'll be talking to my manager though to be extra sure about this. > If not, that's totally fine too, as long as we have a CLA. > In that case, if I may, I'd suggest to concentrate as much time as > possible on documentation. I don't know about other developers, > but personally, I'm not familiar with any of the technologies mentioned in > the microservice project README. > Totally agree, and exactly the path we're taking. For the moment, documentation is being added to the project's site here https://camptocamp.github.io/geoserver-microservices/ What's published there so far is insufficient but there's more structured technical documentation in the works. I'll try to sync the GSIP timing with enough documentation there. Cheers, Gabriel. > Not worried about learning mind, I've just come out of a few months spent > on DGGS concepts and a new OLAP database, > but the OGC testbed gave me opportunity and time to learn those new bits, > which I did not have yet on the techs you're mentioning above. > > Cheers > Andrea > > == GeoServer Professional Services from the experts! Visit > http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf > Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa > (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 > http://www.geo-solutions.it http://twitter.com/geosolutions_it > ------------------------------------------------------- *Con riferimento > alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - > Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni > circostanza inerente alla presente email (il suo contenuto, gli eventuali > allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i > destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per > errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le > sarei comunque grato se potesse darmene notizia. This email is intended > only for the person or entity to which it is addressed and may contain > information that is privileged, confidential or otherwise protected from > disclosure. We remind that - as provided by European Regulation 2016/679 > “GDPR” - copying, dissemination or use of this e-mail or the information > herein by anyone other than the intended recipient is prohibited. If you > have received this email by mistake, please notify us immediately by > telephone or e-mail.* > -- Gabriel Roldán
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
