[osgeo4w-dev] OSGeo4W Governance

[Frank Warmerdam]

Jürgen E. Fischer wrote:
> Hi Frank,
> 
> On Thu, 18. Feb 2010 at 11:39:58 -0500, Frank Warmerdam wrote:
>> I would suggest at least myself, Jeff McKenna, Jürgen Fischer, and Matt Wilkie
>> as members of the PSC.
> 
> Thanks for mentioning me.  I'm flattered :)  

Jürgen,

You are the most prolific contributor!

>> Further, I would suggest we have a category of member which is a packager.
>> Packagers should generally have a good degree of autonomy within the packages
>> they manage as long as they operate within the guidelines of OSGeo4W.  I
>> sincerely wish we had a much more rigerous approach to keeping track of our
>> packages, and who the packagers are for those packages.  We have many
>> packages in the system without any clear idea of who is responsible for them.
> 
> Thanks for not mentioning me, although I feel like you did.

:-)

> I must admit that I don't create a wiki page for each package I created.  The
> ownership of the package files should be a hint for other packagers - but
> obviously not for the users.
> 
> I'd never really liked the wiki approach and have been pretty lazy about it.
> Could we add a packager field to the setup.hint and/or have a defined spot for
> a readme and/or changelog in the OSGeo4W tree?  Something that could be
> automatically checked and complained about when setup.ini is rebuild?

Well, I suppose this is the benefit of a PSC.  We have a process to decide
whether or not we will maintain a Trac wiki package list instead of us
stumbling along without partial involvement.  I think we need a more
substantial piece of documentation that we can point users to about packages.
For instance, I try to include special details about packages including
OSGeo4W specific patches, the use of "gdal version init scripts", how to get
dlls for ecw and so on.  But I will try to make a case for this as an RFC and
we can hopefully come to some joint conclusion on it.

>> At some point we will also have to change some other fundamental components,
>> such as the version of Python we deploy.  These are transitions that will be
>> difficult to manage.  Instead of treating them piecemeal, it might make sense
>> to have a major "version upgrade" every year or two when we essentially build
>> all the packages from the ground up.
> 
> Probably the most promising approach.  Although that might lead to dropping
> packages that are not longer maintained, but in the end that might be a good
> thing anyway.

Agreed.

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/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent