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

[Dmitriy Baryshnikov]

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.

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