<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="generator" content="Osso Notes">
<title></title></head>
<body>
<p>----- Original message -----
<br>> On Sat, Apr 17, 2010 at 02:58:13PM +0200, <a href="mailto:christopher.schmidt@nokia.com">christopher.schmidt@nokia.com</a>
<br>> wrote:
<br>> > > For all intents and purposes those patches
<br>> > > are dead. If we had git, it would be much easier to maintain those
<br>> patches
<br>> > > somewhere until somebody decides what to do with them.
<br>> >
<br>> > Would it be easier than putting them into an SVN sandbox?
<br>>
<br>> Yes. I'd rather have one place for all my stuff (my git repository) than
<br>> a
<br>> different one for each project.
<br>>
<br>> > > Maybe they go into
<br>> > > core, maybe they'll end up in some community maintained "extras"
<br>> repository,
<br>> > > maybe they'll forever be just part of my personal "fork".
<br>> >
<br>> > All of which can still happen without Git.
<br>>
<br>> Yes, but git was designed for this. Why not use it.
<br>
<br>OL sandboxes were designed to solve this problem before Git made sense: why not use them?
<br>
<br>> > > > I realize that this is mostly a selfish point of view, but I fear
<br>> > > > making it easy for organizations to fork, whether it be big or
<br>> small.
<br>> > > > THe motivation to contribute back to OpenLayers is reasonably
<br>> small
<br>> > > > already, due to the turnaround time on OpenLayers mainline
<br>> commits;
<br>> > > > moving to Git to me feels like simply giving up.
<br>> > >
<br>> > > I agree with Chris that the current OL management has worked well
<br>> for the
<br>> > > core of OL, but I think that git could help all those at the fringes
<br>> of
<br>> > > OL experimenting with new functionality. Those people on the
<br>> fringes,
<br>> > > if you keep them happy, some of them will move into core
<br>> development.
<br>> > > In the long run, they'll keep the project healthy.
<br>> >
<br>> > So, I guess the question is: "Why aren't OL sandboxes being used for
<br>> this?" I always started the sandbox development idea with that in mind,
<br>> and I think that other projects have had success with this model within
<br>> SVN (GDAL, for example); why is that not working for OL?
<br>>
<br>> Barrier of entry, again. I didn't even think about asking for sandbox
<br>> access,
<br>> because I think of it as something only for "serious" OL developers.
<br>
<br>A social bug: the entire goal around sandboxes was the opposite of that.
<br>
<br>> A
<br>> git
<br>> repository has a lower barrier, because you don't have to ask anybody
<br>> and
<br>> because it *feels* easier.
<br>
<br>"You don't have to ask anyone" is technically fixable. The latter sounds like a personal preference; reasonable, but I wouldn't agree personally.
<br>
<br>> I don't have to think about whether the stuff
<br>> I
<br>> am working on is "important" enough for a sandbox.
<br>
<br>"Yes" :) Regardless of the stuff, the answer to this should always be "yes."
<br>
<br>> I can just play with
<br>> it
<br>> in my own backyard (ie git repos) and it still can be shared. And if I
<br>> work
<br>> on 10 different things I can have them in one repos or in 10.
<br>>
<br>> I think we are talking about two different things here and we should
<br>> keep
<br>> them separate: One is the SVN vs. git technical debate. The other is the
<br>> question on how to encourage more people to get involved with the
<br>> project.
<br>> You are probably right if you say everything that can technically be
<br>> done
<br>> with SVN can be done with git. But thats not the important point. Both
<br>> these
<br>> names stand in a way for different development models. SVN for a more
<br>> centralized approach and git for the more distributed approach.
<br>
<br>Our SVN sandbox model was designed as a centrally located home for those things which might otherwise go to Git. Having it centrally located lets other OL devs participate, and lets other people find it -- GitHub encourages this, but Git in general doesn't solve that problem.
<br>
<br>> I think I prefer the distributed approach, but I am a bit unclear on
<br>> where you
<br>> stand. You say you "fear making it easy for organizations to fork", yet
<br>> you
<br>> want the sandbox model (which creates lots of forks, doesn't it?).
<br>
<br>My concern is private, hidden, or ill-published forks. Public forks are great: more development is better. Private forks hide useful code from the world. Sandboxes are a great way to create public, open forks.
<br>
<br>-- Chris</p>
</body>
</html>