[gdal-dev] [PSC] Integration of GSoC code : RFC or not ?

[Even Rouault]

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
> > gdal-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html