[OpenLayers-Dev] GitHub straw poll

[christopher.schmidt at nokia.com]

----- Original message -----
> On Sat, Apr 17, 2010 at 02:58:13PM +0200, christopher.schmidt at nokia.com<mailto:christopher.schmidt at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20100417/87c0f11f/attachment.html