[fdo-internals] Please review: RFC 69 implementation

[Greg Boone]

Hi Jackie, 

I can't see any obvious issues with the code, and the code looks like it follows all the correct FDO development strategies. I know you had added many new unit tests, which is great. 

However, there are many changes and a simple code review will not catch potential issues when this new provider is used in client applications such as Autodesk Map and Autodesk Civil. Has any client side testing been performed using such desktop clients? If not, then once it is submitted some regression testing will need to happen on that side. That will have to be co-ordinated with Kevin Campbell. It might be wise for someone on his team to build and test this provider with the FDO 3.9.0 release.

I have no objections to the provider going into Trunk.

Greg

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Monday, October 20, 2014 12:25 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] Please review: RFC 69 implementation


Hi Jackie,

Speaking as the original author of this provider: I didn't follow the thread in detail at the time, but I did look over the changes. I didn't comment at the time, because it's been years since I've done anything FDO, so I didn't think it's appropriate for me to either review the code in detail or approve/disapprove of the change.

Personally, I am neither for nor against this change. The initial implementation of the provider was done in the way it was specifically in order to show an example of how one could create a minimalist FDO provider with as little code as possible. If I remember correctly, it was just one or two source files total and it took about a day to write. So it was intentionally done differently compared to other providers.

That said, if someone wants to take the provider and maintain it in the future, then it's fine if they refactor it into something that they want, as long as the functionality also increases. If the functionality or maintainability does not increase, then refactoring for the sake of refactoring is not worth it.

Thanks,
Traian



-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jackie Ng
Sent: Monday, October 20, 2014 4:02 AM
To: fdo-internals at lists.osgeo.org
Subject: Re: [fdo-internals] Please review: RFC 69 implementation

I am dismayed at the lack of responses to my request for a code review of my RFC 69 implementation.

This RFC represents a significant enhancement to the OGR provider in terms of functionality, stability and usability. I *want* to see these changes make it into trunk and eventually the next release of FDO. I am happy to follow procedure, that's why I rolled back the initial merge with no objections when I was told these changes required code review.

What I am not happy about is when I then proceed to ask for a code review, I get no responses for over a month since the request, especially when I had invested time in implementing these changes. My initial request was on *September 5th*. It has been 1.5 months since then, with no sign from anyone confirming that these changes are ok to merge.

So what's it going to be?

- Jackie





--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Please-review-RFC-69-implementation-tp5160162p5168345.html
Sent from the FDO Internals mailing list archive at Nabble.com.
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals