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

[Jan-Benedict Glaw]

On Tue, 2006-07-04 13:19:03 +0200, Immanuel Scholz <immanuel.scholz at gmx.de> wrote:
> 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.

Well, I'll add my statements, too. If system administration is needed,
I'd step in. No problem. If server programming needs to be done, I'd
be fine with it, too.

Except... There's one thing that hinders me a bit: Ruby.  I'm a C guy.
Maybe I can write some limited stuff in other languages as well, but
for everything I want to have control over, or fast execution speed,
I'll use C.

> 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

There are other projects heading in a similar direction.  To test new
code, be it server-side code or client applications, I guess it'd be
more interesting to /not/ work with real data, but with a fixed set of
example data. Let's just pick a square mile (or kilometer:-) from
somewhere and use this for testing.

Prerequisite: Easy server setup.

> 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.

Debugging is a thing of its own... I'm not even convinced that it's a
bright idea to call the data-accepting and exporting functions through
a real web server.

If we think a bit further, it might be interesting to come up with a
cluster-based design for the whole thing, with whatever DNS
round-robin, loadbalancer or proxying stuff is needed to catch
maps.google.com in the long term :-)

> 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.

It's harder than it needs to be. But what sucks the largest rocks, at
least for my point of view, is setting up the web server, including
Ruby, and hacking Ruby...

> 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.

While the database scheme may look complicated, bloated or whatever, I
actually think that's a feature, really. Especially the history stuff.
What is possibly missing is a bit of documentation describing the
overall idea, the whole picture, to get the guys started with it. Once
you understood the semantics of it, and that it contains more than the
"current" state, it's all quite clear.

> 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

That's just a simple organization thing. Let's just put the SVN
revision number somewhere and the whole discussion is over.

> (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.

It would help in some cases, but after all, I think it should be
moderately easy to get an example server set-up and put some example
data into it.

> 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.

I'm just a bis distracted by Ruby. All the rest can easily be fixed.
Just send patches :-)

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw at lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20060704/06e3b723/attachment.pgp>