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

[Even Rouault]

Le mercredi 19 octobre 2011 22:04:47, Etienne Tourigny a écrit :
> 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.

Sounds reasonable. But as I said, I would not want to set constraints on you 
on this. I'm well aware it can be costly. We have no rules on that, so it is 
left to your judgement.

> 
> 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.

Sounds reasonable

> 
> 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