[fdo-internals] Dropping off PSC

[Greg Boone]

Hi Daniel, Frank,

Is it possible for one or both of you to take a look at the MITAB changes that Leaf and Aleck made, and offer guidance on how we can move towards having the proposed changes, or a variation of the changes, integrated into the MITAB trunk? 

http://code.google.com/p/groundnut/

If you can outline what has been done vs. what needs to be done, and propose ideas on how to get from here to there, we can determine if the community can find the resourcing required to make up the delta. 

Greg


-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Daniel Morissette
Sent: Friday, October 29, 2010 5:02 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] Dropping off PSC

Greg Boone wrote:
> Well, as for MITAB, I too am in favor of a non-fork strategy. I would like to see the code moved back to the original repository. Maybe a further discussion could be undertaken by the members of the FDO community on how that can be accomplished. 
> 

Hi Greg, and PSC,

I'm sure you realize how disappointed I am after reading this FDO RFC 54
and your decision to fork MITAB (for those who don't know yet, I am the
original MITAB developer). In my opinion, none of the technical reasons
expressed in RFC 54 and in the thread earlier this week on this list
warrant a fork.

I'm glad you're in support of returning the code to MITAB, but hopefully
you realize that contributing back is not as simple as dumping a mega
patch on me or other MITAB/OGR devs. Each change needs to be reviewed
and considered in light of its impacts on the library, its users, and in
this case on OGR since it is used as part of OGR as well.

Just to make things worse, I have some unreleased code here in the
development version of MITAB that sets the bases for random update...
not much yet because the project for which I was doing it (unrelated to
FDO or ADSK) got canceled a while back, but I've put some thinking into
it and have some code already. It's a shame that nobody asked me before
working on a fork, you could have started from my dev version instead of
the latest public release... now instead we are in presence of a real
fork since my changes for read/write access are very likely incompatible
with those made by Leaf and Alex... just more headaches to deal with for
a potential merge.

(For the record, I had been in touch with some people at ADSK interested
in MITAB r/w support 2-3 year ago and had told them that I was working
on it already... that was before this other project got cancelled... so
I am in part to blame for never releasing a version of MITAB with r/w
support after saying for several months that it was coming... but I
still wish someone had talked to me before forking.)

> 
> That being said, whatever options are proposed needs to have a realistic chance of funding, support and maintenance going forward. Autodesk has, and is currently providing support and funding in areas where it feels it gets value for its money, In doing so it supports maintenance of fdo and the current list of providers, builds, defect fixes, etc. The King organization does the same. I would like to see more individuals and organizations advocate for their interests as well, fund appropriately, and champion their requirements and needs in a similar manner. 
> 

Very good point, but open and proactive communication doesn't cost that
much.

I'd also add that the chances of myself or another MITAB or GDAL/OGR dev
putting energy into a merge of an eventual mega-patch after the fact
will also depend on available funding.

Daniel
-- 
Daniel Morissette
http://www.mapgears.com/
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals