[OpenLayers-Dev] GitHub straw poll

[Sebastian Benthall]

Just 2 cents--

I've spent a good deal of time in 'sandbox hell.'  My own fault, to be sure.
 But I have often felt that more sophisticated merge tool's like gits' would
have helped me get out of it: more fluidly contributing back from a sandbox
on which some app I was working on depended and pulling core work back in,
with the goal of getting all the way back to core.

(These were cases where my development schedule made it hard to be a good
citizen in the short run.)

As for unpublished forks, one nice thing about github is that it tracks
forking, provides notifications, and generally encourages the social network
around the network of code branching and experimentation so that the
community isn't lost despite the decentralization.



On Sat, Apr 17, 2010 at 10:56 AM, <christopher.schmidt at nokia.com> wrote:

>  ----- Original message -----
> > On Sat, Apr 17, 2010 at 02:58:13PM +0200, 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
>
>
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>
>


-- 
Sebastian Benthall
OpenGeo - http://opengeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20100419/e038b459/attachment.html