Hello all, Geoffrey Furnish writes: > The main purpose in this post is just to sample the other developers, all > of you who are currently much more actively involved in PLplot than I am, > or even than I expect to be once I regain my stride, so to speak, and just > see if any of you would be interested in seeing PLplot switch to git. > > Here's the SF page relating to project git support: > > http://apps.sourceforge.net/trac/sourceforge/wiki/Git > > Is anyone besides me interested in making the switch to git for the PLplot > project?
Thanks for all the responses I received. Besides those that responded on list, I got other private mail. The private mail expressed great interest in seeing PLplot switch to git, from people who, probably kinda like the sentiments Maurice expressed, view git as a very positive direction to be moving, but hoping to avoid being directly embroiled in any controversy or work stemming from such a move. Very understandable. Alan was the only one who expressed a specific desire to avoid switching on a short time scale. And of course some of our core developers didn't touch the topic at all. So what now? Well, I'm planning for a cutover to git. The questions in my mind mostly surround how to do this in a way that keeps all core developers engaged and not alienated. I certainly understand why several of the responses, both public and private, gave ascent to the notion of potential controversy. So, while I do definitely want to see PLplot move to git, I don't want current core developers to feel railroaded. It seems clear that a wholesale instantaneous cutover is simply unattainable at this time. This due to social concerns rather than technical ones. Plenty of projects have made the switch, and preserved history, etc. Even one very large, high profile project announced just such a cutover just during the time since I opened the topic for discussion here. But without a clear consesnsus for such a turnkey switch, I won't advocate such a cutover for this project, at least not at this time. Instead, in the interest of promoting the sort of exposure (to git and the way(s) of working with it) that I think would be persuasive to those who are possibly interested but not yet ready to cast a vote, so to speak, I will instead put some energy into what I might call a "transition tools"-oriented approach. What I mean by this, specifically, is that I will open a PLplot git repo with one of the open-source git hosting services. I propose not to use SF for this, because from reading the SF docs, I can't really tell that they provide the facilities both for tracking svn with git, and then subsequently replacing svn with git (which is my ultimate goal). So, I'm thinking its best to keep the SF git option unactivated for now, and instead do the PLplot git stuff through one of the other git hosting services. I know of two at this time: github and gitorious. I've learned that I'm not the first to do this, by the way, there's someone who's already started a PLplot "fork" at github. I don't know if there are other git hosting options, so I anticipate picking between one of these two, and setting up a git repo there sometime in the near future. I want to point out, however, that the one I intend to set up, will not be a "fork" of the project. Now, obviously I can't control what others do, but what I'm saying is, the PLplot git repo I intend to establish will not itself, support checkins from other people that could lead to it becoming an unsync'd and therefore diverging "fork" from PLplot's SVN master. Rather, what I plan to do is make an svn-tracking repo somewhere in my private space, and then "publish" from this (these) repo(s) to the public one. That will give people an opportunity to see what I'm doing and/or collaborate with me via git. But no one will be able to commit directly to that public git repo. Instead, if someone want's to collaborate with me on some activity that's in a git branch that I'm working on, they'll be able to see my intermediate states through this git collaboration hub. They can pull from there. But to get their additions committed upstream, they'll either need to send me some git-am output, or else give me something I can pull from, etc. Then, the upward push to the plplot SF svn repo will happen through my private git-svn repo which itself treats SF svn as its origin. I think a key point for me here, will be to facilitiate similar git-svn tracking by other PLplot folks who want to track the SF svn repo, but wish they could use git to do it. I was pleasantly surprised to learn, both from e-mails, and from discovering plplot "git forks" out there, that others have beaten me to this. I don't know if this stuff has gotten public billing before, perhaps while I was in corporate e-mail lockdown over the past year, or if this is really the first time any of this stuff has gotten public air. No matter, frankly. The point is, I want to make it as easy as possible for people who would like to be using git for plplot work, to do so. So, I'll plan to post (ultimately in the SF svn repo), some docs on how to do with git-svn, the kinds of things I'm doing. And it seems others are possibly farther along with git-svn than I am, so perhaps I will learn more than I offer here, but anyway, let's get that ball rolling. So, bottom line, I intend to start supporting use of git in plplot development now. To begin with, this will be mostly oriented toward helping individuals explore git, but we will stick with git-svn repos that track the SF svn PLplot master. Everyone using svn will be able to continue doing exactly as they do now, with no change to their working style whatsoever, if they choose. Hopefully, with some exposure to git over time, it will be possible for the group to agree to actually switch the master repo over to git. To that end, I'd like to ask Alan specifically, again, to identify with specificity, what you think the specific requirements for such a transition would be, from your perspective. My own view of this list would be, essentially: 1) Preservation of history 2) Demonstration that checking out tagged versions between SF svn and a potential git successor repo, results in the same files with the same attributes. Frankly those are the only things I can really see as preconditions, and these are things which I believe are basically in the bag now (with git-svn import). Maybe demonstration of this is all that's needed? Or maybe there are other requirements that others have that I haven't thought of yet. If so, I'd like to know about them. Like, for instance, is there anything in the release-cutting process which depends on svn commands, for which git workalikes would have to be fielded? Or anything else. Whatever the list is, I'd like to know what it is, since that's the only way a person could make tangible concrete progress toward resolving the issues. Gotta know what they are, with sspecificity. Comments welcome. I'll post a followup to this when I have a public git repo for PLplot that people can clone/pull. Finally, btw, I just wanted to point out that one thing I discovered in the past couple weeks, is the huge amount of git workflow documentation and tutorials that are available through github. I learned git mostly from the man pages that come with git. But at github there's a ton of material for learning git that seems new since I was a git beginner. (And I'm still a beginner as far as git-svn is concerned). Cheers, -- Geoff ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
