[osgeo4w-dev] OSGeo4W Governance

[Matt Wilkie]

I welcome the opportunity to continue to help osgeo4w grow and develop. 
Thank you.

Packaging indeed needs to be thought about. For the "who is maintaining" 
aspect: maybe packages which have not been touched in NN-months get 
dropped from the [curr] ent package list? (with advance notice to the 
current maintainers' email address, and the mailing list.)
> Arguably we could dispense with the distinction and treat the PSC as being
> the collection of all packagers.
Definitely all packagers should have a voice.  If it's a committee with 
all on equal footing pulling off major upgrades like standardizing on 
gdal1.7 and python3 will be hard and long; there are over 60 names in 
/home (not sure how many of those are osgeo4w specific).

Also on the packaging front it'd be great if the osgeo4w specific part 
of them were part of a version control system. For example I'd like to 
make some small changes to the default postinstall method for making 
menu and desktop links. It'd be easier for one person do this in a 
centralised location than sending nag messages out to dozens of 
packagers, who likely want to focus on the application itself and thus 
will let small fiddly things sit in the waiting room until there is no 
choice. I've no idea how to accomplish this as everything in one big 
repository would clearly be too much. Launchpad perhaps? <shrug>

In any case, the above is diving into specifics and is more properly 
part of an RFC process.  I agree that it might be the right time to 
formalize how major decisions are made, with just enough governance to 
be functional.

matt wilkie
--------------------------------------------
Geomatics Analyst
Information Management and Technology
Yukon Department of Environment
10 Burns Road * Whitehorse, Yukon * Y1A 4Y9
867-667-8133 Tel * 867-393-7003 Fax
http://environmentyukon.gov.yk.ca/geomatics/
-------------------------------------------- 



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.
>
> Best regards,
>