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 [email protected] ## N49°00'09" E008°23'33" _______________________________________________ dev mailing list [email protected] https://lists.openstreetmap.org/listinfo/dev
