[osgeo4w-dev] OSGeo4W Governance

[Jeff McKenna]

Frank,

Thanks for taking the time to put your thoughts together on OSGeo4W 
governance.

Like your GDAL and Python 'standard' issues, I also see a few issues 
coming up that should be discussed as a PSC beforehand rather than just 
'it's committed, please update server'.  For example: Hayashi-san and I 
will be proposing a change to the first window (instead of just 
'express' and 'advanced', propose something like 'Express Desktop 
Install', 'Express Web GIS Install', and 'Advanced Install').  This 
proposed change has come from suggestions from users.  (in fact 
Hayashi-san and his team are working on this now) Additionally, many 
users are saying that the Advanced window contains too many confusing 
dev versions and libs of packages, making it unusable for them - we will 
also be proposing to create an 'OSGeo4W Users Edition' of the installer 
which contains only stable versions (no libs or dev packages).  We will 
of course produce RFCs for both of these.

So I think the timing is good to setup a PSC.

I agree that being a packager for OSGeo4W needs to be taken more 
seriously, or at least we need to be recording who is packaging what.

For the PSC, I would second your suggestions, and also add Yewondwossen 
Assefa (who was has been involved since the beginning, but I have not 
verified with him yet if he is interested in being on the PSC), and also 
Hirofumi Hayashi (who is very honored to be considered for the PSC, may 
have not been visible before but has a strong interest in this 
product...indeed in a very short amount of time his team have made some 
great improvements in the product)

Hopefully you don't think this is too many PSC members - it is a big 
project with many packages, so I think it warrants a little more 
representation.

I would like to start writing these 2 RFCs as soon as we make a decision 
on the governance.

(Hayashi-san and Venka have added their roles in the wiki)

-jeff


Frank Warmerdam wrote:
> Folks,
> 
> I have felt for some time that it would be desirable to somewhat formalize
> the governance of OSGeo4W but I have hesitated to bring anything forward in
> part because I have scaled back somewhat on my time commitment to OSGeo4W
> and thus find it difficult to follow through on significant new 
> initiatives.
> 
> However, in light of recent questions, I'd like to bring forward some
> preliminary thoughts.
> 
> I would like to suggest we have a Project Steering Committee, roughly in
> the vein of other OSGeo projects.  The PSC would vote in the usual fashion
> on any contentious OSGeo4W issues.   Major new policies, and major 
> transitions
> could be written up as RFCs for voting.
> 
> I would suggest at least myself, Jeff McKenna, Jürgen Fischer, and Matt 
> Wilkie
> as members of the PSC.
> 
> 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.
> 
> Arguably we could dispense with the distinction and treat the PSC as being
> the collection of all packagers.
> 
> Thoughts?  Should I try to write up a modest governance RFC?
> 
> -- 
> 
> For the most part we haven't had a strong need for voting in the past since
> we have pretty much stuck with an existing approach to things.  But I think
> we have a few decisions to make reasonably soon to keep OSGeo4W relevant.
> 
> I want to roll out GDAL 1.7 as the "standard" GDAL.  This has a distinct
> ABI from GDAL 1.5, and this has the potential for significant disruption to
> existing packages.   Pulling off a transition could be tricky.
> 
> 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.
> 
> I'm concerned that many of our packagers are fairly inactive and it may be
> difficult to pull such a transition off.
>