[OpenLayers-Dev] RFC: Migrating OpenLayers SVN + Trac to OSGeo infrastructure

[Paul Spencer]

Chris,

I think this is a good move to make for the project, and for OSGeo as  
well.

I don't have any particular feeling about the structure of URLs and  
would be fine with either structure.

While I'm not involved personally in SAC, I would like to help and I  
can ask Shawn Barnes to help out with any migration support that you  
need.

Cheers

Paul

On 13-Jan-08, at 7:03 AM, Christopher Schmidt wrote:

> OpenLayers is currently (graciously) hosted by MetaCarta. This has
> worked out quite well so far, but using MetaCarta hosting has meant
> we've had to 'roll our own' system for authentication -- and as many
> people know, this particular system is rather hacky: an email to the  
> PSC
> list to generate a new username, which requires manual intervention.
>
> Part of the reason that I've never improved upon this system is that
> I've always felt that it would be better to invest in moving to OSGeo
> infrastructure. For a while, this was difficult, but recently, OSGeo  
> has
> found some solutiosn which make this technically possible.
>
> I'd like to suggest that we move to OSGeo infrastructure for hosting
> Trac and the Wiki as soon as possible. I'm less sure on the website  
> and
> mailing lists.
>
> Benefits of moving svn + wiki:
> * Users can create their own userid -- or use their existing osgeo
>   userid -- to login to either.
> * Users creating tickets in trac will automatically get email  
> notification
>   on updates of their tickets.
> * It will be possible to register oneself as a "CC" on a bug without
>   exposing an email address to the public web.
> * Shared administrative resources with OSGeo -- which means that it's
>   not just me who can update the server, but instead the set of people
>   who maintain the OSGeo servers
> * Shared OSGeo backup infrastructure. Currently, we're backing up
>   OpenLayers internally to MetaCarta, and exporting data to OSGeo:
>   moving to OSGeo infrastructure allows for the bcakups to be
>   maintained by the foundation.
>
> The strongest one to me is that users will be able to create their own
> accounts via an automated process - no humans involved. I think this  
> is
> very important.
>
> I have a couple of questions which I don't personally have an answer  
> to
> yet:
>
> Currently, all OSGeo svn, trac, etc. live under URLs like
> http://trac.osgeo.org/gdal/ , http://svn.osgeo.org/gdal/ . I do not  
> know
> if it is possible to configure svn.openlayers.org to point directly to
> the OSGeo server, or if it would be preferred for administrative
> purposes to have it at svn.osgeo.org/openlayers/ . Obviously, even if
> it's trivial in an administrative way, it would be more in line with  
> the
> rest of the foundation-hosted projects to have the URL be
> svn.osgeo.org/openlayers/ . Assuming that there is sufficiently good
> infrastructure setup to allow for users to migrate from one to the
> other, would it make sense to make the primary OpenLayers SVN URL be  
> the
> osgeo.org/ form?
>
> Same question applies to trac.
>
> I view these aspects of the project as 'internal' -- where SVN lives
> doesn't matter much, so long as it's correctly linked everywhere --  
> and
> would be in support of moving into the osgeo.org namespace for svn and
> trac, with appropriate redirects.
>
> A similar question applies to mailing lists. Currently, these lists  
> are
> dev at openlayers.org and users at openlayers.org. Moving to OSGeo
> infrastructure would probably mean moving these to
> openlayers-users at lists.osgeo.org and openlayers-dev at lists.osgeo.org  
> (and
> openlayers-trac and openlayers-commits.) Would it make sense to move
> these, with proper redirects to lists.osgeo.org for both the email
> addresses and the archives?
>
> Speaking as (essentially) the sole maintainer of the machine that
> openlayers.org is hosted on, I'd like to move off whatever we can to
> OSGeo infrastructure. As you can see here, one important piece of the
> infrastructure piece is left aside, and that's the sandboxes, website,
> etc. I think the important aspect of those changes is related to the
> regular 'svn up' and rebuilding that happens. In the past, we've
> discovered that doing these in post-commit hooks is bad, because it
> takes too long to commit (which would be een more true now with the
> NaturalDocs stuff). However, I think that we can devise a technical
> solution -- using a post-commit hook to write a revision number, and a
> cronjob to check whether changes have been made and rebuild if so. I
> think this would allow us to move to OSGeo infrastructure for the
> website as well, though there would obviously need to be some  
> technical
> discussions for what we could do as far as doc regeneration, etc.  
> goes.
>
> This is not a motion yet: its a request for comments. I'm interested  
> in
> moving for a number of reasons, both technical and social. Although
> there are other people at MetaCarta with 'the keys' to the servers,  
> I'd
> like to move that out to the foundation -- and I see that we get a  
> fair
> amount of benefit from that. I'm hopeful that others agree, and we can
> discuss the best way to move forward with the goal of making the  
> process
> smooth.
>
> Feedback, comments, suggestions, concerns are welcome.
>
> (Note that at the moment, I'm not looking for technical advice on the
> way to set up redirects or anything like that: we can address that  
> after
> we address whether, and how, we *want* to move first.)
>
> Regards,
> -- 
> Christopher Schmidt
> MetaCarta
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev

+-----------------------------------------------------------------+
|Paul Spencer                          pspencer at dmsolutions.ca    |
+-----------------------------------------------------------------+
|Chief Technology Officer                                         |
|DM Solutions Group Inc                http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+