[Community] Future of gispython.org repositories

Discussion:

Sean Gillies

2011-07-09 20:07:27 UTC

Hi all,

My server that hosts the gispython.org site and services runs on
Ubuntu 6.06.1 LTS, which has reached its end of life. I'm facing a
fair amount of work in migrating my personal stuff, and more in
migrating the various code repositories and trac instances that we've
been sharing. I invite you to question with me whether migrating the
gispython.org Subversion repos and Trac instances and databases is
worth the effort.

When Kai and I started collaborating in 2005, we agreed that
Sourceforge wasn't for us. There weren't any clear alternatives at the
time (this was before OSGeo and long before Bitbucket and GitHub) and
I was fired up to learn how to deploy Subversion, so we set up our own
development infrastructure. Now, of course, there are many excellent
alternatives to Sourceforge with features that the gispython.org
infrastructure can't match. I'm thinking specifically of GitHub's fork
and merge buttons, and Gists. Whether you agree with them or not, to
an increasingly large crowd of programmers, it doesn't count if it's
not on GitHub (or Bitbucket or Google Code if you will). The harder I
look at migrating the gispython.org stuff, the more I think that all
we get for the price of migration is just more obscurity,
marginalization, and eventual stagnation of the projects.

Howard has taken the Spatialindex and Rtree projects to GitHub.
Shapely is already there. The various zgeo.* packages I propose to
either move to the Pleiades SVN or merge into Plone's collective.geo.
The only other active and therefore seriously impacted project is
OWSLib. Dear OWSLib developers: would you be willing to take the
project to Google Code or OSGeo (to keep SVN) or to GitHub or
Bitbucket (necessarily switching RCS) in the next month or so?

--
Sean Gillies
Programmer
Institute for the Study of the Ancient World
New York University

Volker Fröhlich

2011-07-10 07:40:06 UTC

Permalink

QGIS recently switched from SVN to Git and from OSGeo to Github. They also
migrated their bug tracker from Trac to Redmine.

A couple of people were involved in the migration. You might want to ask Tim
Sutton about what problems they encountered.

Kind regards,

Volker

Post by Sean Gillies
Hi all,
My server that hosts the gispython.org site and services runs on
Ubuntu 6.06.1 LTS, which has reached its end of life. I'm facing a
fair amount of work in migrating my personal stuff, and more in
migrating the various code repositories and trac instances that we've
been sharing. I invite you to question with me whether migrating the
gispython.org Subversion repos and Trac instances and databases is
worth the effort.
When Kai and I started collaborating in 2005, we agreed that
Sourceforge wasn't for us. There weren't any clear alternatives at the
time (this was before OSGeo and long before Bitbucket and GitHub) and
I was fired up to learn how to deploy Subversion, so we set up our own
development infrastructure. Now, of course, there are many excellent
alternatives to Sourceforge with features that the gispython.org
infrastructure can't match. I'm thinking specifically of GitHub's fork
and merge buttons, and Gists. Whether you agree with them or not, to
an increasingly large crowd of programmers, it doesn't count if it's
not on GitHub (or Bitbucket or Google Code if you will). The harder I
look at migrating the gispython.org stuff, the more I think that all
we get for the price of migration is just more obscurity,
marginalization, and eventual stagnation of the projects.
Howard has taken the Spatialindex and Rtree projects to GitHub.
Shapely is already there. The various zgeo.* packages I propose to
either move to the Pleiades SVN or merge into Plone's collective.geo.
The only other active and therefore seriously impacted project is
OWSLib. Dear OWSLib developers: would you be willing to take the
project to Google Code or OSGeo (to keep SVN) or to GitHub or
Bitbucket (necessarily switching RCS) in the next month or so?

Jachym Cepicky

2011-07-11 05:30:31 UTC

Permalink

I can only agree, that redmine is much better than trac, but, it is
written it ruby and so it is more tricky to setup (for python-people
at least).

But the result is worth it.

Jachym

Post by Volker FrÃ¶hlich
QGIS recently switched from SVN to Git and from OSGeo to Github. They also
migrated their bug tracker from Trac to Redmine.
A couple of people were involved in the migration. You might want to ask Tim
Sutton about what problems they encountered.
Kind regards,
Volker

_______________________________________________
Community mailing list
Community at lists.gispython.org
http://lists.gispython.org/mailman/listinfo/community

--
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp

Kralidis,Tom [Ontario]

2011-07-11 14:13:47 UTC

Permalink

-----Original Message-----
From: community-bounces at lists.gispython.org
[mailto:community-bounces at lists.gispython.org] On Behalf Of
Sean Gillies
Sent: Saturday, 09 July 2011 16:07
To: gispython.org community projects
Subject: [Community] Future of gispython.org repositories
Hi all,
My server that hosts the gispython.org site and services runs
on Ubuntu 6.06.1 LTS, which has reached its end of life. I'm
facing a fair amount of work in migrating my personal stuff,
and more in migrating the various code repositories and trac
instances that we've been sharing. I invite you to question
with me whether migrating the gispython.org Subversion repos
and Trac instances and databases is worth the effort.
When Kai and I started collaborating in 2005, we agreed that
Sourceforge wasn't for us. There weren't any clear
alternatives at the time (this was before OSGeo and long
before Bitbucket and GitHub) and I was fired up to learn how
to deploy Subversion, so we set up our own development
infrastructure. Now, of course, there are many excellent
alternatives to Sourceforge with features that the
gispython.org infrastructure can't match. I'm thinking
specifically of GitHub's fork and merge buttons, and Gists.
Whether you agree with them or not, to an increasingly large
crowd of programmers, it doesn't count if it's not on GitHub
(or Bitbucket or Google Code if you will). The harder I look
at migrating the gispython.org stuff, the more I think that
all we get for the price of migration is just more obscurity,
marginalization, and eventual stagnation of the projects.
Howard has taken the Spatialindex and Rtree projects to GitHub.
Shapely is already there. The various zgeo.* packages I
propose to either move to the Pleiades SVN or merge into
Plone's collective.geo.
The only other active and therefore seriously impacted
project is OWSLib. Dear OWSLib developers: would you be
willing to take the project to Google Code or OSGeo (to keep
SVN) or to GitHub or Bitbucket (necessarily switching RCS) in
the next month or so?

I can't speak for Dom, but my pref would be OSGeo infrastructure to keep
a similar infrastructure (I'll ask). OWSLib has (at least) to projects
tied to it (pycsw, qgcsw) which both use svn:externals to pull in OWSLib
trunk. Having said this, I would not be against other ideas.

..Tom

Dominic Lowe

2011-07-11 15:46:39 UTC

Permalink

Post by Kralidis,Tom [Ontario]

I would be happy with joining up with OSGeo and I think it could be a
good thing for OWSLib - however my understanding is that the OSGeo
incubation process will be more demanding than signing up with
googlecode or github. We have to meet various acceptance criteria etc.

If speed is of the essence then perhaps we use something like googlecode
for now (therefore keeping SVN) with a view to OSGeo incubation over the
next few months?

Regards,

Dom

Post by Kralidis,Tom [Ontario]
_______________________________________________
Community mailing list
Community at lists.gispython.org
http://lists.gispython.org/mailman/listinfo/community

--
Scanned by iCritical.

Howard Butler

2011-07-11 15:49:50 UTC

Permalink

Post by Kralidis,Tom [Ontario]

There's no need to incubate to move to OSGeo's infrastructure. You just need to find someone on the OSGeo System Administration Committee to help bootstrap your project migration. You can even join SAC yourself and make it happen.

In my opinion, github's a better solution to allow wider friction-free contribution than OSGeo. Centralized source control is an evolutionary dead end. OSGeo taking on SVN/Trac in 2006 made much more sense then than it does now.

Howard

Kralidis,Tom [Ontario]

2011-07-11 15:50:08 UTC

Permalink

-----Original Message-----
From: community-bounces at lists.gispython.org
[mailto:community-bounces at lists.gispython.org] On Behalf Of
Dominic Lowe
Sent: Monday, 11 July 2011 11:47
To: community at lists.gispython.org
Subject: Re: [Community] Future of gispython.org repositories

Post by Kralidis,Tom [Ontario]

project to

Post by Kralidis,Tom [Ontario]

Google Code or OSGeo (to keep
SVN) or to GitHub or Bitbucket (necessarily switching RCS) in the
next month or so?

I can't speak for Dom, but my pref would be OSGeo infrastructure to
keep a similar infrastructure (I'll ask). OWSLib has (at least) to
projects tied to it (pycsw, qgcsw) which both use svn:externals to
pull in OWSLib trunk. Having said this, I would not be

against other ideas.

Post by Kralidis,Tom [Ontario]
..Tom

This is true. That and someone's time to do the port.

If speed is of the essence then perhaps we use something like
googlecode for now (therefore keeping SVN) with a view to
OSGeo incubation over the next few months?

Google Code is fine with me. Should we discuss a migration plan?

..Tom

Dominic Lowe

2011-07-11 15:57:42 UTC

Permalink

Post by Howard Butler
There's no need to incubate to move to OSGeo's infrastructure. You just need to find someone on the OSGeo System Administration Committee to help bootstrap your project migration. You can even join SAC yourself and make it happen.
In my opinion, github's a better solution to allow wider friction-free contribution than OSGeo. Centralized source control is an evolutionary dead end. OSGeo taking on SVN/Trac in 2006 made much more sense then than it does now.
Howard

Howard,

Thanks for the clarification on OSGeo incubation.

Dom

Post by Howard Butler
_______________________________________________
Community mailing list
Community at lists.gispython.org
http://lists.gispython.org/mailman/listinfo/community

--
Scanned by iCritical.

Sean Gillies

2011-07-11 17:52:19 UTC

Permalink

Post by Dominic Lowe

There's no need to incubate to move to OSGeo's infrastructure. ?You just
need to find someone on the OSGeo System Administration Committee to help
bootstrap your project migration. ?You can even join SAC yourself and make
it happen.
In my opinion, github's a better solution to allow wider friction-free
contribution than OSGeo. ?Centralized source control is an evolutionary dead
end. ?OSGeo taking on SVN/Trac in 2006 made much more sense then than it
does now.
Howard

Howard,
Thanks for the clarification on OSGeo incubation.

--
Sean

Dominic Lowe

2011-07-12 08:08:36 UTC

Permalink

That sounds good to me.

Dom

On 11 Jul 2011 18:52, <sean.gillies at gmail.com> wrote:

On Mon, Jul 11, 2011 at 9:57 AM, Dominic Lowe <dominic.lowe at stfc.ac.uk>

On 11/07/11 16:49, ...

Dom, Tom:

How about this for a schedule:

7/22: new home picked and initialized
7/22-7/29: svnsync to new home (example
http://code.google.com/p/support/wiki/SubversionFAQ#How_do_I_import_an_existing_Subversion_repository?
),
dump owslib component tickets from Trac db to an SQL file.
7/29: redirect OWSLib wiki traffic to new home

--
Sean

_______________________________________________
Community mailing list
Community at lists.gispython.org...
--
Scanned by iCritical.

--
Scanned by iCritical.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gispython.org/pipermail/community/attachments/20110712/ef214fca/attachment-0001.htm>

Kralidis,Tom [Ontario]

2011-07-12 15:05:51 UTC

Permalink

+1.

I think, for the purpose of migrating, something trac/svn would be
suitable, and we can look at git down the road if the requirement
evolves. Any objections to this? If none, then it's either googlecode
or osgeo. I would prefer osgeo, but we need SAC hands to help out, or
someone can sign up for SAC and do it themselves. Any interested
volunteers?

..Tom

On 11/07/11 16:49, ...

7/22: new home picked and initialized
7/22-7/29: svnsync to new home (example
http://code.google.com/p/support/wiki/SubversionFAQ#How_do_I_i
mport_an_existing_Subversion_repository?),
dump owslib component tickets from Trac db to an SQL file.
7/29: redirect OWSLib wiki traffic to new home
--
Sean
_______________________________________________
Community mailing list
Community at lists.gispython.org...
--
Scanned by iCritical.

Dominic Lowe

2011-07-12 16:28:11 UTC

Permalink

Tom,

I'm not in a position to volunteer to do much at the moment but I
support a move to OSGeo if we have the help/resources and certainly no
objections. For me the move to OSGeo would not be so much about svn v
git but about moving towards the OSGeo community.

Cheers,
Dom

Post by Kralidis,Tom [Ontario]
+1.
I think, for the purpose of migrating, something trac/svn would be
suitable, and we can look at git down the road if the requirement
evolves. Any objections to this? If none, then it's either googlecode
or osgeo. I would prefer osgeo, but we need SAC hands to help out, or
someone can sign up for SAC and do it themselves. Any interested
volunteers?
..Tom

On 11/07/11 16:49, ...

_______________________________________________
Community mailing list
Community at lists.gispython.org
http://lists.gispython.org/mailman/listinfo/community

--
Scanned by iCritical.

Kralidis,Tom [Ontario]

2011-07-13 17:21:12 UTC

Permalink

FYI I've filed a trac ticket to OSGeo:
http://trac.osgeo.org/osgeo/ticket/739

-----Original Message-----
From: community-bounces at lists.gispython.org
[mailto:community-bounces at lists.gispython.org] On Behalf Of
Dominic Lowe
Sent: Tuesday, 12 July 2011 12:28
To: community at lists.gispython.org
Subject: Re: [Community] Future of gispython.org repositories
Tom,
I'm not in a position to volunteer to do much at the moment
but I support a move to OSGeo if we have the help/resources
and certainly no objections. For me the move to OSGeo would
not be so much about svn v git but about moving towards the
OSGeo community.
Cheers,
Dom

Post by Kralidis,Tom [Ontario]
+1.
I think, for the purpose of migrating, something trac/svn would be
suitable, and we can look at git down the road if the requirement
evolves. Any objections to this? If none, then it's either
googlecode or osgeo. I would prefer osgeo, but we need SAC

hands to

Post by Kralidis,Tom [Ontario]
help out, or someone can sign up for SAC and do it themselves. Any
interested volunteers?
..Tom

-----Original Message-----
From: community-bounces at lists.gispython.org
[mailto:community-bounces at lists.gispython.org] On Behalf

Of Dominic

Post by Kralidis,Tom [Ontario]

Lowe
Sent: Tuesday, 12 July 2011 04:09
To: community at lists.gispython.org
Subject: Re: [Community] Future of gispython.org repositories
That sounds good to me.
Dom
On Mon, Jul 11, 2011 at 9:57 AM, Dominic Lowe

On 11/07/11 16:49, ...

_______________________________________________
Community mailing list
Community at lists.gispython.org
http://lists.gispython.org/mailman/listinfo/community

--
Scanned by iCritical.
_______________________________________________
Community mailing list
Community at lists.gispython.org
http://lists.gispython.org/mailman/listinfo/community

Christian Ledermann

2011-07-14 07:51:48 UTC

Permalink

My only concern is:

You have to put a message like

MOVED_TO_GIT.txt:
this project is no longer actively developed here. it has been moved to .....

into the current svn.

It is annoying when you try to fix a bug, google for the repository
check out the code, svn di your fix. send the diff to the maintainer -
only to find out that this is already fixed, you just had an outdated
version of the repository

also once projects are moved, there should be a redirect from the
'old' to the 'new' location

just my 2c
--
Best Regards,

Christian Ledermann

Nairobi - Kenya
Mobile : +254 702978914

<*)))>{

If you save the living environment, the biodiversity that we have left,
you will also automatically save the physical environment, too. But If
you only save the physical environment, you will ultimately lose both.

1) Don?t drive species to extinction

2) Don?t destroy a habitat that species rely on.

3) Don?t change the climate in ways that will result in the above.

}<(((*>