Le mercredi 23 juillet 2014 15:49:22, Dmitriy Baryshnikov a écrit : > Hi, > > As a mentor of Mikhail project this is my responsibility to maintain the > code after the GSoC and also we have in our GSoC plan all necessary > steps to integrate all the results to GDAL. The GNM has not make great > changes in current GDAL source tree: new folder and several new > applications in apps folder. So I don't see any problems with > integration and maintaining this.
Hi, From a discussion with FrankW, we think that it would be appropriate for Mikhail to still write a RFC. I think Mikhail must already have good material to write it from his blog posts, so hopefully that will not require a too much effort, and will give the PSC and the community a good picture of the new functionnality, and that will also be able to serve for users as a good reference. Answering below to a few points. Even > > Best regards, > Dmitry > > 23.07.2014 17:09, Jukka Rahkonen пишет: > > Wolf Bergenheim <wolf+grass <at> bergenheim.net> writes: > >> I'm not PSC but, since I have some experience in GSoC I thought I should > > > > speak up. > > > >> The fact that GDAL accepted Mikhail as a GSoC student sort of covers the > > > > RFC part. GSOC proposals don't necessarily go into technical details on how the code is organized, which is one of the purposes of a RFC. > > Because there he proposed his project and the PSC should have > > voted for or against this project if not wanting it in. This might be a process issue, but the PSC has not voted for or against any project proposal. Only proposed mentors and OSGeo GSOC administrators do. > > In any case the > > Project proposal can be copy-pasted into an RFC in case you do want to > > have an RFC for the record. > > > >> Also it's sort of implied in the GSoC program that the aim is to add > >> code Indeed, but the activity of coding also implies designing, documenting, testing and following the general process of the project. > > > > to the trunk of a project, unless stated otherwise. And to me this seems > > to have been the goal of this project too. > > > >> So that being said, as long as the code meets the expected standards and > > > > it should as long as the mentor is doing his job, I don't see any > > obstacles, RFC is already technically written and so has the code, and > > the assigned mentor should maybe give a vote of confidence, and that > > should sort of be it. Personally I don't see a reason to vote if the > > Mentor is for merging Mikhail's code. > > > > I think that with larger projects like GDAL or Geoserver (which I follow > > as a member of PSC) it is not reasonable to think that the code from > > GSoC projects could generally go directly into trunk. Students are > > supposed to program something useful in a relatively short time and > > taking care of all the extra stuff that is needed before code can be > > accepted into trunk can be out of the scope of GSoC and students may not > > be able to do it even with the help from their mentors. The code in > > trunk must not break anything and it should compile not only now but > > also in the future which means that someone must take the responsibility > > of maintaining the code. Geoserver is a bit different project with lots > > of pluggable modules but the Community module policy is worth reading > > http://docs.geoserver.org/stable/en/developer/policies/community-modules. > > html. > > > > I would say that editing the GSoC project plan into RFC and making the > > PSC to vote if the code meets the standards by quality, license and > > other IP stuff, and future maintainability would be a good idea and > > re-usable in the future. > > > > -Jukka Rahkonen- > > > > > > > > > > > > > > _______________________________________________ > > gdal-dev mailing list > > [email protected] > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Geospatial professional services http://even.rouault.free.fr/services.html _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
