[gdal-dev] proposed changes to netcdf export behaviour (perhaps RFC)

Etienne Tourigny etourigny.dev at gmail.com
Wed Oct 19 16:04:47 EDT 2011


Even,

I've been thinking about this, and I knew you were going to prefer
incremental changes, as it would be preferable.  However, there's
about a month of development in there and it would be quite difficult
to try to separate things in small chunks.
It will also be difficult because there has been significant
refactoring, due to the export of lon/lat values for projected crs.
Also if I commited all the changes (it's possible with my workflow),
there would be quite many patches and it would be difficult to follow.

Probably what I will do is make a diff and see if I can break it up
into different parts. Perhaps I can separate import, export and misc
parts into separate commits - how about that?
I will wait a few days (we are still doing some benchmarks and final
testing) and then go through the commit process.

There will also be a significant refactoring for the adding of a
Create() function (just the export part), but I want to push through
these changes first.

salutations,
Etienne

On Wed, Oct 19, 2011 at 5:49 PM, Even Rouault
<even.rouault at mines-paris.org> wrote:
>> > As PSC chair I will not be offended if you proceed with netcdf changes
>> > *without* a formal RFC type vote on the changes.  The changes are fixing
>> > bugs and don't cause real backward compatability issues and I'm willing
>> > to treat you as the authority/owner for the driver.
>>
>> OK Frank, many thanks for you support and trust
>
> I also totally share Frank's opinion. All the efforts you have lead seem to
> have been carefully thought about and are well documented (in the wiki, but
> frmt_netcdf.html would perhaps need updates). Plus I'd have difficulties to vote
> for a RFC with an enlightened mind on such a specialized topic ;-)
>
> How will you proceed to updating in SVN ? A big code drop, or apply
> incremental changes ? Personnaly, I tend to prefer micro changes to be able to
> track regressions more easily, but it might be hard with the workflow you
> followed using git? I'd note that merging a svn branch in trunk would also
> loose incremental steps. That's just questions to satisfy my curiosity: I
> don't ask you to "rewrite history" as they seem to do in Linux kernel
> development.
>
>>
>> > Best regards,
>> > --
>> > ---------------------------------------+---------------------------------
>> > ----- I set the clouds in motion - turn up   | Frank Warmerdam,
>> > warmerdam at pobox.com
>> > light and sound - activate the windows | http://pobox.com/warmerda
>> > and watch the world go round - Rush    | Geospatial Software Developer
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>


More information about the gdal-dev mailing list