[pgrouting-dev] State of OSGeo migration

Daniel Kastl daniel at georepublic.de
Wed Jul 28 10:17:48 EDT 2010


Hi Steve,

Thank you very much for your comments!
At least I know now that my email got out ;-)



> Sounds like a frustrating experience. Just an FYI to put things in
> perspective. One (or more) of the OSGeo servers got hacked and I think
> rootkited recently which has had the admins working overtime trying to setup
> replacement servers and to clean up the mess that that caused.


Yes, I know about that incident and I don't want to be on behalf of the
admin team. They also did some server migration recently.
That they are too busy is probably one reason why it's maybe better they
concentrate on the OSGeo projects instead of become an FOSS4G sourceforge
;-)
Somehow I feel if you need to belong to the "club" of SAC that everything
goes smoothly.




>
>> Everything went quick but SVN migration became frustrating and I started
>> to think if it's really a good idea to use OSGeo servers if the OSGeo
>> administrators seem to be a bit too much busy. They are all volunteers, so I
>> appreciate their work. But there were a couple of issues with the servers
>> the last weeks, so I started to look for alternatives:
>>
>
> You have only discussed alternative software and not alternative hosting
> opportunities, like SourceForge, Google, other OSGeo supporters like
> MapGears, etc.
>

I didn't know about MapGears, but I almost checked every important candidate
on this list:
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
It more or less depends on what version control system you want to use.
There is also Launchpad, which would be convenient for me, because I'm
building pgRouting packages there for Ubuntu. But probably people would get
mad at me if I would propose Bazaar.



>
>     * SUBVERSION alternative:
>>
>>      Recently a lot of projects use distributed version control systems
>>      like Git, Mercurial or Bazaar. Especially Git seems to become more
>>      and more popular. Just a few weeks ago OpenLayers started to work
>>      on version 3 using Github for example.
>>      In my opinion a move to Git would make participation of developers
>>      without commit access easier. It would allow others to make use of
>>      version control without losing versioning information, so it would
>>      allow us to bring changes from other projects back into the main
>>      project. You see, I'm still hoping for contributions ;-)
>>
>
> Personally, I like subversion because I know it and it is used on most of
> the other projects that I use. I suppose I can learn Git if we were to move
> that direction. I think OpenLayers is moving that direction for Rev 3.0.
>
> Another option would be to host it in SVN on say SourceForge.
>

Git attracts a lot of people at the moment, almost everyone around me is
using it. I made the pgRouting workshop together with Frederic Junod from
Camptocamp and we used Git. It was quite convenient, and I feel it makes it
easy for others to make a "fork" (that's how they call it) and have the
possibility to bring back changes of these forks into the main project,
because forks are like branches and they keep their history.

In my opinion pgRouting lost acouple possible contributers in the last years
by the way SVN is restricted to selected people. I'm not only thinking of
pgRoute here. Most developers will never ask you for commit rights.

With SourceForge I'm somehow not so happy and it's probably just this
annoying download page that you probably know. ;-)



>
>     * FORUM alternative:
>>
>>      The forum is a problem in my opinion. First it's missing
>>      notification, second it's more or less Anton and me answering 99%
>>      of the questions, and third it attracts a lot of spam, which I'm
>>      tired to delete. Spam filters don't work. On the other hand it's a
>>      lot more popular than the mailing list, so we would probably take
>>      a away a popular resource for pgRouting users. It seems the entry
>>      level to ask in a forum is a lot lower than to signup for the
>>      mailing list.
>>      So my idea would be something like "Stackoverflow". There is an
>>      open source alternative called "Shapado", which you can install on
>>      your own server, but also use a hosted installation. At the moment
>>      I would prefer the latter, and to see how it looks like I setup
>>      this for testing: http://ask.pgrouting.org/
>>
>
> Ha, I was not aware that we had a forum. I prefer a mailing list that is
> gated to nabble. We do not have a lot of traffic on the list and spam is not
> a big problem there. If we didn't have a forum, most of the spam would go
> away, casual viewers could read about it in nabble and serious users that
> need help would join the list for it.
>

Yes, it's not called "Forum", it's called "Discussion". It's amazingly
popular. I think three to four times of questions compared to the mailing
list.
Nabble is a good idea ... somehow I failed to use it in a proper way,
probably didn't get it. I think Nabble is good for those, who are used to
mailing lists.

I'm not saying we don't need a mailing list, I just wanted to replace the
current "Discussion" in TRAC, because it's an extension and we probably
can't install it on OSGeo or any other hosted TRAC. Hard to say what would
happen if we only had a mailing list. Would everyone ask there instead?
Would users just stop to ask?



>
>     * TRAC WIKI alternative:
>>
>>      The number of TRAC users is probably already several thousand ...
>>      99% spam accounts though. You can't delete them anymore through
>>      the web interface, because user management with TRAC sucks. On the
>>      other hand, there are just a few people editing the TRAC wiki, so
>>      I don't think a wiki is really necessary. People tend to write
>>      their recipes in their own blog anyway.
>>      I would propose to use Sphinx documentation generation to produce
>>      static HTML and PDF as so many other OSGeo projects do now. My
>>      experience with Sphinx is very good since I wrote the FOSS4G
>>      workshop manual with it, and also the pgRouting chapters of the
>>      next LiveDVD documentationt. We can keep the website documents
>>      under version control and make it accessible under pgrouting.org
>>      <http://pgrouting.org> domain (there is no problem to host it on
>>
>>      the Georepublic server from my side).
>>
>
> Again, you can get svn, trac, wiki all integrated at SourceForge. Maybe I'm
> wrong but I don't see that much spam on the OSGeo wiki's because you have to
> have an OsGeo login and if you spam any wiki you get booted pretty quickly.
>
> For documentation +1 on Sphinx (this is ReStructed Text, correct?) and
> keeping them under version control.
>

You mean the OSGeo TRAC wiki? Could be spamfree because they use a very
unique login system. But I know that OpenLayers and GeoExt for example also
have to fight spam. Actually it's just the discussion forum that makes
problems. And the users added by bots, because it makes it almost impossible
to administrate.
It was my hope to get rid of it by using OSGeo TRAC ...

Regarding SVN you are right. SorgeForge is a good option if we want to stay
with SVN (or Google as well). It was my idea to make it easier for others to
participate and contribute, so I would be in favor of a distributed version
control system. Can be Mercurial as well or Bazaar. It's more or less all
the same with different names. Github recently allows to create
"Organizations" (or you can call it groups). Otherwise there is Gitorious as
well. I even heard that OSGeo has a Git repository for GSoC, right?



>
>     * TRAC TICKETS alternative:
>>
>>      Probably it would be easiest to use the Github ticketing system if
>>      we decide to use Github.
>>
>
> The OpenLayers team looks at the Github ticketing system and said it was
> poor and they decided to keep tickets in trac.


Yes, I heard so, too. But I also think that the problem of pgRouting tickets
is currently less the platform we use than how we handle them. Currently
they are a big mess even if we use TRAC ;-) I sometimes think TRAC tickets
are too complicated to understand for people who file a ticket ... or maybe
we configured them wrong, I'm not sure.
I think simple is better, but I must admit that I didn't test GitHub tickets
in detail yet.



>
>
>  If you have any comments, please let eevryone know.
>> Otherwise I would be interested to know who agrees or disagrees with this
>> change of RFC 2.
>> If everyone agrees I will change RFC 2 (or make RFC 3) and proceed like
>> described above.
>>
>
> I appreciate all your efforts in this and can empathize with your
> frustration when getting this done is largely at the hands of over worked
> admins. I need to look at the ticket thread, but has OSGeo said no we are
> overloaded? or when we get to it? or what? I assume that once we are moved
> it would be less of a hassle and would be handled in the normal course of
> their business.
>
> So, I guess I'm asking is this a case of wait to get the job done at OSGeo,
> or we really don't think it will get done or even if it gets done we don't
> think they can support our small project for whatever reason?
>
> -1 on changing direction, at least until I have more information.
>

OK, that's not so bad idea. A few weeks more doesn't matter anymore after
months of waiting ;-)
Maybe for you the answer of Christopher Schmidt is more clear. Here's our
conversation:
http://osgeo-org.1803224.n2.nabble.com/Project-Hosting-td5178588.html

And this is the ticket for SVN: http://trac.osgeo.org/osgeo/ticket/561

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20100728/54ad1660/attachment-0001.html


More information about the pgrouting-dev mailing list