[OSM-dev] lack of server coders (was: London Undergroundstations?)

Andy Robinson Andy_J_Robinson at blueyonder.co.uk
Tue Jul 4 14:38:52 BST 2006


And to follow with the others, I have no objection whatsoever to my map data
edits being associated with me as a user of OSM. As for GPX tracks, the
provisions in place (should I occasionally wish to make a gps track private)
are good enough for me.

Cheers

Andy Robinson
Andy_J_Robinson at blueyonder.co.uk 

>-----Original Message-----
>From: dev-bounces at openstreetmap.org [mailto:dev-bounces at openstreetmap.org]
>On Behalf Of Ben Gimpert
>Sent: 04 July 2006 13:19
>To: dev at openstreetmap.org
>Subject: Re: [OSM-dev] lack of server coders (was: London
>Undergroundstations?)
>
>Hi OSM,
>
>I don't want to chime in on *all* the complaints being raised, but I
>would like to consider a couple:
>
>I agree with Imi that the "privacy crutch" has become a bit absurd.
>Therefore, I ask that the community respond to this message with a yea
>or nea on their inclusion on a "white list" of those who don't give a
>shit if the NSA knows they were at Starbucks at 9:37am this morning.
>
>More formally, I hereby publicly announce that every single OSM entity I
>have ever modified or contributed, and every entity I *will* ever modify
>or contribute, may be freely associated with my "identity" (i.e. email
>address) by anyone, at any time.
>
>If you are also tired of the privacy crutch -- I'm talking to you, Imi
>and Christopher -- please consider agreeing the statement above. My
>lifestyle is just not interesting enough for me to wear an OSM tin hat.
>
>I also agree that installing and configuring a local development server
>is extremely difficult, and this is a significant impediment to more
>developers working on the project.
>
>Now, as for Steve taking down the server -- I don't mind if he shits on
>and then kicks the server into The Thames without telling anyone.  Until
>someone else steps forward to volunteer as OSM Systems Administrator,
>the intermittence of availability is something we must to acomodate.
>
>As for the very harsh accusation of hoarding the project, we should
>remember that Steve is not the only one possibly empire building.  Over
>a *month* ago, I asked for SVN commit permissions to one of OSM's sister
>projects but the request has met with definitive silence.
>
>		A black kettle,
>		Ben
>
>
>On Tue,  4 Jul 06 @01:19pm, Immanuel Scholz wrote:
>> Hi,
>>
>> Steve complained about the few coders interested in coding the server.
>>
>> Lars replied (not to specific this, but in general):
>> > But if I'm the only one who feels like this, then this project is far
>> > smaller than it should be.  And then we have to ask: Why is it still so
>> > small, why aren't we attracting more contributors?  Why are newcomers
>> > turned away?
>>
>> For me, I have to cleary say that the lack of testing and debugging
>> capabilities and in the server code keep me away. I tried several times
>to
>> change that but each time I got stopped by Steve thinking testing and
>> debugging is either just fine now or not that important.
>>
>>
>> To be more specific about my current problems:
>> 1) I need a real database snapshot. Or a planet.osm containing enough
>> stuff in the area I want to develop. When Steve thinks privacy is a
>> problem, the author field can be randomized. However, I think now that
>> Steve's concern is much different than privacy but instead he does not
>> want to give out the data because someone else could "steal" his project.
>> If this is really the case, I am off to a more open team. To me, OSM is
>> about distributing the data and encourage people to do every possible
>> stuff with it, not to gather as much as possible and then provide the
>> loudest grumbler with some morsel of XML.
>>
>> 2) Debugging capabilities are important. If you never used a debugger
>> (except some hacked printf-statements), then I am not suprised that the
>> server code is in such terrible performance and design condition.
>> dev.openstreetmap.org is nice for integration testing but it is not a
>> server for development.
>>
>> 3) The setup-process of a development server was terrible, last time I
>> checked. Most projects achieve a "configure && make dev" or something
>like
>> that. The last time I checked for OSM, it was far from that away. Steve
>> said it improved and several people succeeded in setting up their home
>> server. I don't believe him.
>>
>> 4) The database layout and the access classes look really scary and
>> overbloated to me. Last time someone suggested a clean reimplementation,
>> Steve almost fall off his seat about this (not surprisingly, since it is
>> his code). But if I would have to work on the server code, a major
>> overlook would be the first thing to do. If Steve's attitude is to
>prevent
>> people from doing this, few server coder will join the team.
>>
>> 5) There is no coordinated deployment process. The code goes sometimes
>> magically from the subversion into the running server (usually by Steve).
>> Coders are not sure what version currently runs - if the subversion is
>> more current than the server code or the other way round. Although
>someone
>> (Christoph?) said before, that this is his usual experiences from real
>> life projects, I disagree. In all other project, at least the coders (or
>> the ones that should become coders) are perfectly informed what runs on
>> the server and most times they also knew when the next server update is
>> scheduled. I think this greatly helps when just playing around with the
>> code or when bug hunting a specific problem.
>>
>>
>> A failure in any of these five points is enough reason to me to not code
>> anything within the server's codebase. I like to help, but then something
>> must be changed in OSM.
>>
>>
>>
>> Ciao, Imi
>>
>>
>>
>> _______________________________________________
>> dev mailing list
>> dev at openstreetmap.org
>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
>
>_______________________________________________
>dev mailing list
>dev at openstreetmap.org
>http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev







More information about the dev mailing list