[OpenLayers-Dev] GitHub straw poll
christopher.schmidt at nokia.com
christopher.schmidt at nokia.com
Sat Apr 17 10:56:56 EDT 2010
----- Original message -----
> On Sat, Apr 17, 2010 at 02:58:13PM +0200, christopher.schmidt at nokia.com<mailto:christopher.schmidt at nokia.com>
> > > For all intents and purposes those patches
> > > are dead. If we had git, it would be much easier to maintain those
> > > somewhere until somebody decides what to do with them.
> > Would it be easier than putting them into an SVN sandbox?
> Yes. I'd rather have one place for all my stuff (my git repository) than
> different one for each project.
> > > Maybe they go into
> > > core, maybe they'll end up in some community maintained "extras"
> > > maybe they'll forever be just part of my personal "fork".
> > All of which can still happen without Git.
> Yes, but git was designed for this. Why not use it.
OL sandboxes were designed to solve this problem before Git made sense: why not use them?
> > > > I realize that this is mostly a selfish point of view, but I fear
> > > > making it easy for organizations to fork, whether it be big or
> > > > THe motivation to contribute back to OpenLayers is reasonably
> > > > already, due to the turnaround time on OpenLayers mainline
> > > > moving to Git to me feels like simply giving up.
> > >
> > > I agree with Chris that the current OL management has worked well
> for the
> > > core of OL, but I think that git could help all those at the fringes
> > > OL experimenting with new functionality. Those people on the
> > > if you keep them happy, some of them will move into core
> > > In the long run, they'll keep the project healthy.
> > So, I guess the question is: "Why aren't OL sandboxes being used for
> this?" I always started the sandbox development idea with that in mind,
> and I think that other projects have had success with this model within
> SVN (GDAL, for example); why is that not working for OL?
> Barrier of entry, again. I didn't even think about asking for sandbox
> because I think of it as something only for "serious" OL developers.
A social bug: the entire goal around sandboxes was the opposite of that.
> repository has a lower barrier, because you don't have to ask anybody
> because it *feels* easier.
"You don't have to ask anyone" is technically fixable. The latter sounds like a personal preference; reasonable, but I wouldn't agree personally.
> I don't have to think about whether the stuff
> am working on is "important" enough for a sandbox.
"Yes" :) Regardless of the stuff, the answer to this should always be "yes."
> I can just play with
> in my own backyard (ie git repos) and it still can be shared. And if I
> on 10 different things I can have them in one repos or in 10.
> I think we are talking about two different things here and we should
> them separate: One is the SVN vs. git technical debate. The other is the
> question on how to encourage more people to get involved with the
> You are probably right if you say everything that can technically be
> with SVN can be done with git. But thats not the important point. Both
> names stand in a way for different development models. SVN for a more
> centralized approach and git for the more distributed approach.
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.
> I think I prefer the distributed approach, but I am a bit unclear on
> where you
> stand. You say you "fear making it easy for organizations to fork", yet
> want the sandbox model (which creates lots of forks, doesn't it?).
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dev