----- Original message ----- > On Sat, Apr 17, 2010 at 02:58:13PM +0200, > christopher.schm...@nokia.com<mailto:christopher.schm...@nokia.com> > wrote: > > > For all intents and purposes those patches > > > are dead. If we had git, it would be much easier to maintain those > patches > > > 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 > a > different one for each project. > > > > Maybe they go into > > > core, maybe they'll end up in some community maintained "extras" > repository, > > > 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 > small. > > > > THe motivation to contribute back to OpenLayers is reasonably > small > > > > already, due to the turnaround time on OpenLayers mainline > commits; > > > > 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 > of > > > OL experimenting with new functionality. Those people on the > fringes, > > > if you keep them happy, some of them will move into core > development. > > > 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 > access, > 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. > A > git > repository has a lower barrier, because you don't have to ask anybody > and > 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 > I > 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 > it > in my own backyard (ie git repos) and it still can be shared. And if I > work > 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 > keep > 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 > project. > You are probably right if you say everything that can technically be > done > with SVN can be done with git. But thats not the important point. Both > these > 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 > you > 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. -- Chris
_______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
