[OSM-dev] OSM binary format (pbf) 1.0 is in osmosis trunk.

Stefan de Konink stefan at konink.de
Sun Oct 17 19:35:30 BST 2010

Hash: SHA512

Hi Frederik,

Op 17-10-10 20:11, Frederik Ramm schreef:
> (1) every project will have to have a maintainer who decideds what gets
> pulled into trunk - this introduces more formality than we have now;

Maybe our data is informal. I rather not have code to be informal,
directly the reason why I choose a GIT repository: people can branch my
code create mess, fix stuff up and send it back.

> (2) as a committer, I want it to be *my* decision whether I commit
> something right away - in cases where I'm sure it is good - or whether I
> want to discuss with others first. That's in keeping with the spirit of
> OSM where you don't have to ask for permission to edit the map.

If someone exposes peoples privacy, will his commits right be reverted?

> (3) as a user, I will have to hunt through mailing lists and whatnot and
> compile the cryptic URLs of private repositories to pull from, rather
> than having a one-stop shop.

If it /is/ a one-stop shop, make svn accessible with the OSM
credentials, just see what happens.

> ... git may offer more
> flexibility but compared with OSM where everyone gets SVN access...?

So 'everyone' is not 'everyone' by default?

> But as I said - it doesn't have to be either-or, you can go ahead with
> the cutting edge development on git and we can every now and then pull
> something workable into SVN, with a big README that says please apply
> changes to git only.

I thought by now there are svn2git bridges. So can we please not
bikeshed about what kind of versioning system we use, instead ask
ourselves why it took two weeks to get the serious bugs out of an app...
because just nobody cared?

And the point is, if I release the pbf version of your tool... when can
we make sure that people start caring about it?

Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the dev mailing list