[OSM-dev] OSM software repositories -- git and svn

[Frederik Ramm]

Hi,

   this is a discussion/brainstorming about if and how to get rid of
what remains of the OSM project SVN.

Let me first say what I liked about SVN:

* I liked that there was a project-wide SVN without any privilege
hierarchies. Everyone could ask for an account, and then they could
commit changes to everything.

* I liked that there was one canonical version of everything in the SVN,
and that I could change the canonical version instantly, instead of
making my own copy of it and then asking someone to somehow accept my
change.

* I liked that I could disown stuff into SVN - "here's a small script I
wrote, I don't intend to maintain it really, but feel free to
use/improve it" and that others could then contribute to something like
that without actually having to take ownership, and without users having
to track whose version was currently the one to use.

* I liked that things were discoverable - if someone made an obscure
script that deals with .poly files then it was very likely that it would
be found in the appropriate SVN directory, rather than under a fancy
repo name somewhere in github,

* I liked that it was ours, and not dependent on the goodwill or
cooperation of a third party operator.

What I picture here is a, sometimes precarious, version of collective
ownership. It is not suitable for large, highly visible project with a
solid contributor base - for example, JOSM has always been developed
outside of the project SVN even while that was still in vogue.

One of the main criticisms of our SVN is that it is full of cruft that
doesn't even work anymore, and while there are plenty github repos that
share the same fate, this laissez-faire attitude to project ownership
might well contribute to that. I would be more likely to clean something
up if it was a repository listed under my name in github that something
that I dumped into SVN five years ago and have since forgotten.

Still I maintain that there is, conceptually, a niche for this "shared
ownership", where the developer community of the whole project has
instant write access to the canonical version of things.

Myself, I've written countless little scripts and snippets that are
shared in SVN. Sometimes people have indeed made their own changes to
them; sometimes my scripts simply live alongside 5 other scripts that
are thematically related (e.g. a collection of utilities that all deal
with .poly files in one way or the other).

The generic approach to something like that today would probably be that
every author creates a github repo for his stuff, potentially granting
others access if they ask. Git and github are simply the way to go these
days, and while some people still shed tears for the good old SVN (or
CVS, or... what was it before that, RCS?) times, it doesn't really make
much sense to have many different technologies for what is essentially
the same basic task of version control.

Assuming for a moment that we would like to drop our SVN altogether and
replace it by git/github - I'd like to discuss the following:

1. collective ownership

Can we maybe have the (fsvo) superior technology offered by git and
still not completely drop the collective ownership idea? Can we somehow
use git(hub) (without totally ab-using it) to create a niche for stuff
that is "not quite a standalone project" and "not necessarily owned by
one single person"? Or am I maybe the only person in the world who sees
some value in that concept?

Should everyone who remotely considers themselves an OSM developer have
write access to the "openstreetmap" repository in github, or should we
create an "openstreetmap-developer" repository for that which would have
a "less official" character? Is there maybe a technical way to grant
write access to the repository to everyone who has an OSM account
without extra signup?

Can we continue to support users who, for privacy reasons, don't want to
work through the github platform but who would rather only communicate
with a server directly under our control?

2. discoverability

I know that there are people who create a github repository for
everything, even if it's just a 30-line text file to maintain. Doing
that for all the conceptually different things that we now have in our
SVN would probably yield something between 200 and 500 "repositories",
and it would be (correct me if I am wrong please) a big step backwards
in discoverability because git(hub) repositories cannot be arranged in
trees - in SVN I can, for example, go to "applications/rendering" or
"applications/utils/export" and do an "ls" there to see.

Would that mean that we'd essentially have to create one big repository
that can hold a ton of completely separate stuff like our SVN does
today? Or would we create hundreds of mini repos and then have a
separate index for them, e.g. a wiki page or a 101st repo? Maybe there's
some state of the art solution for this kind of problem?

3. moving across old stuff from SVN

If we can manage to find a way to give a new home to stuff from SV in
the git universe, we could do that for everything that is still
worthwile (i.e. works and maybe has the occasional contribution), and
archive everything else in a static directory somewhere, and then close
SVN altogether. This should perhaps be done manually so that we can sort
working stuff from really-old-cruft.

I'm interested to hear your thoughts about this.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"