[pgrouting-users] PSC - what next?

Anton Patrushev anton.patrushev at georepublic.de
Tue Mar 30 22:27:21 EDT 2010


Hi list,

>> (1) CONFIRM INITIAL PSC
>>
>>     * I would like to hear from each PSC member on this list what they
>>       think about the PSC guideline and if they are (still) willing to
>>       join (at least a +1 would be nice ;-)
>>     * ... and if anyone wants to submit objections please do it now!
>
> I'll start with a +1. I think the key is to get it going and we can fine
> tune it as time goes by.

+1 from me.

>> (2) MAILING LIST(s)
>>
>>     * Create a "pgrouting-dev" mailing list for further discussion and
>>       also for PSC votes (I don't think we need another mailing list for
>>       PSC)
>
> Agreed.

+1.

>
>>     * Personally I would like to move mailing lists to lists.osgeo.org
>>       <http://lists.osgeo.org>, because it takes responability for
>>       mainteneance from Orkney and I know that it was tricky to setup
>>       for the specific environment. Nevetheless it should be possible to
>>       copy the existing archive of "pgrouting-users" to the new place.
>
> Agreed.

+1. Let's move pgrouting-users to OSGeo also.

>> (3) 1.04 RELEASE
>> As some warming up the new PSC could vote for a bugfix release. For this
>> release I wouldn't follow something like the OpenLayers release process
>> yet, because I think "trunk" has been tested now for more than a year ;-)
>
> Consider the fact that community members often only work with a released
> version and that is all the goes into OS package releases. So the only
> people that have tried trunk are those that need it for a specific bug
> they have hit or those that are knowledgeable enough to muck with the code.
>
> That said, the process would be cut a RC-1 and put it out for N weeks
> and if not issues then cut 1.04.

For that we need to revise all tickets we have now (can be done at the
same time with moving to OSGeo).
I was thinking more about bug fix release than new feature implementation.

>> (4) SVN REPOSITORY
>>
>>     * Install "Submin" to administer user accounts (very convenient tool)
>>     * Discuss repository structure and access rights
>>     * Discuss about the pgRouting "tools" (I'm not so happy with the
>>       current structure)
>>     * Move ot OSGeo infrastructore or not? Maybe pgRouting project can
>>       run on some dedicated virtual server, that more people can have
>>       access to.
>
> I think I might start with OSGeo infrastructure. You might want to
> discss that with Frank W. Another alternative is using source forge. I'm
> sure there are others also as you mentioned.

I think we just keep it very simple for now - let's try not to make an
infrastructural overhead for that small group of people we currently
are.
What we currently need is a bug tracker, mailing lists and very basic wiki/docs.
So, my +1 for using OSGeo tools for now, and will move to something
else once we really need it.

>> (5) TRAC
>>
>>     *  From time to time TRAC spam is quite annoying. Find a solution
>>       for this.
>>     * Discussion/Forum is quite popular and more used than mailing lists
>>       from users, but automatic notification doesn't work (anymore)
>>     * Not sure if we could keep Discussion/Forum extension on OSGeo server
>>     * Not sure how difficult moving TRAC would be
>>     * TRAC is not good in multilingual support (for example Redmine does
>>       much better and also provides subprojects). Is everyone happy with
>>       TRAC?
>>     * Move to OSGeo infrastructore or not? Maybe pgRouting project can
>>       run on some dedicated virtual server, that more people can have
>>       access to.
>
> OSGeo supports Trac and SVN. I think that multilingual documentation is
> more important than Trac. Mapserver keeps its docs in REST (restructured
> text) format which is easily readable as text, but can be formated
> through templates into HTML, PDF, and a lot of other formats. All docs
> are kep in SVN like:
>
> woodbri at carto:/u/software/mapserver-SVN$ ls docs
> conf.py  de  en  labels.py  make.bat  Makefile  _static  _templates
>
> So the initial docs go into en for English and then anyone can clone the
> docs into a new language and translate them. You can use "svn diff" to
> see how and when the en docs changes so you know what needs to be
> updated in the other languages.

My +1 to use OSGeo Trac move existing tickets there.

>> (6) WRITE RFC(s)
>> I think for discussions about new development, roadmap, documentation,
>> etc. we should then use the pgrouting-dev mailing list and write RFC's
>> as Stephen proposed.
>>
>> Any thoughts?
>
> +1 to get going :)

+1 from me.


Anton.




More information about the Pgrouting-users mailing list