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. Because there he proposed his project and the PSC should have voted for or against this project if not wanting it in. 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 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
