From: Geoffrey F. <Geo...@at...> - 2009-03-13 16:44:32
|
Hello all, Greetings after a long sabatical. I've been lately trying again to get re-engaged with PLplot development. One of the first things I'm trying to get done, is to merge the python branch that I had worked on about 15 months ago, and get that stuff onto trunk. Then there is some more python oriented work I'd like to do from there. We've undertaken a few big changes on the PLplot project over the years. I guess the biggest one of late, was the cutover to cmake. Personally, I'm still trying to recover from that. In my outside-PLplot life, I and most people I work with in the professional arena, ditched cvs/svn, and switched to git. For me, and most of my closest professional colleagues, this switch has been both huge, and positive. By a huge switch, I don't so much mean to evoke worries of astronomical catalysis barriers, as just to say that the change to git has had a really big impact on how we do development. I have become so enamored with git, that I have come to view it as somewhat arduous to work with other, lesser systems. SVN is at the top of my personal list of "lesser" systems. Sometimes I wonder if the problem is just lack of education on svn-ways, but I keep running across internet articles where others lament the same difficulties as I have, so I don't think it's just me. Lately, in my attempts to try to get caught up with PLplot, I've actually been using the git svn client to track our git repo. Some of you might've noticed my triffling commits a few days ago. Those were committed using git-svn, with no direct personal interaction with svn itself. 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? On the off chance that there are some of you who don't have a strong opinion yet, and are willing to consider the options, I thought I'd just relate some of my personal experiences surrounding the cutover to git. At my former company, Lightspeed Logic, we eventually realized that we were outgrowing cvs. We hired more people, had more going on, and decided to consider switching SCM's in the interest of promoting team productivity. We did a sort of pilot study, in which people tried out both svn and git, then we had a results comparison meeting, and ended up choosing git. Looking back, the one thing I would say about our efforts to compare svn versus git, is that we were way too gracious to svn in the comparison. The reasons we chose to switch to git instead of svn, proved to be much stronger in retrospect than we realized at the time we made the decision. I really don't want to provoke any sort of major flame war here, so I enter into a discussion of my perception of the technical stuff with some trepidation. Fine with me if others post alternative or contradictory viewpoints, but if it comes to that, let's just keep in mind that we're talking about personal perceptions and experiences. One of the biggest things that hits newcomers to git, is the whole concept of distributed source control. Git docs talk about peer relationships and so on, and people sometimes wonder how you maintain any control in a git-managed project. The git docs sometimes talk as if they're all about empowering anti-establishment rogue coders, and this fuels the perceptions that git is impossible to use for a project where anyone wants a sense of control. My answer to this is that it's just a policy decision, which is outside the space of SCM per se. In other words, you just designate a repo as your "official" project/company repo, and that's it. It's official because you say so, not because it occupies any particular point in the software collaboration interaction diagram. SF provides a technique for hosting and communicating with that repo, so it's not at all hard for us to establish the identify of the "master project repo". The policy needs to bbe backed up with some relatively straightforward understandings, such as, releases will be built from tags present in the project master repo, etc. The next big thing to understand about git is that it makes branching beautiful. Others have written about the mechanisms of git branching, so I won't go into the mechanisms. I just want to talk here about the experience, so to speak. In git, you can fork a branch in a heartbeat. You can switch beetween branches just as fast. Well, you might want to do a commit of your work before switching away from a branch, but anyway its still fast. And you can merge branches essentially willy-nilly, and git always seems to know what you're doing. With cvs, you could fork a branch, work on it for a while, then merge it back to the head. As long as you used branches that way, they worked okay. In svn, it seems--almost unbelievably--worse. Apparently to do branch work right in svn, you have to actually keep crib notes of your revisions for subsequent manual merging. Frankly what I've read about it in the context of svn has been so off-putting, that it's the main reason I haven't merged the python branch back to trunk yet. The way I'll get it done, at this point, is probably going to be through git (using git svn if PLplot stays svn-centric). With git, when you want to merge a branch, you just say git merge <other branch>, and that merges other branch into your current branch. And this works in all directions. You can merge topic branches into master, quickly and easily. And you can merge the master branch into your topic branch just as easily. This lets you "track" trunk (called master in git-speak), easily, while maintaining as-yet unfinished topic work on a topic branch, until it's really ready to merge. If I had to pick one thing about git which is truly superlative, it's the branch management. But, there isn't just one thing about git which makes it great. It's beyond being just merely "great" because of so many features that all conspire together to make git a true game-changer in the world of SCM. The next thing to understand about git is that it supports a wide variety of what I call "collaboration paradigms". And I could hardly write down all the possible work flows. Instead, let me just paint a picture of a few. 1) The same-old same-old cvs/svn approach, practiced with git. The project has a master repo, the one at SF. Developers clone it. They change code, check it in (git commit) to their local repo. Developers do "git pull" to track upstream changes. Developers do "git push" to push their changes up to the project master repo. 2) Individuals using branches, still mostly centralized The project has a master repo, the one at SF. Developers clone it. Developers create topic branches, do work thereupon. Developers push their branches up to the project master repo, as well as their changes to the master branch. Developers occasionally merge topic branches to the master branch, and push up this result of integration. 3) "Distributed development gone wild" The project has a master repo, the one at SF. Developers clone it. Developers create topic branches, do work thereupon. Developers publish their changes to "collaboration hubs". Other developers pull back and forth from their peers on as-interested basis. Eventually subteams decide something is "done enough for public consumption". Someone does a git co masster; git merge topic; git commit; git push origin to make the multi-developer topic branch integrated into the master branch and available in the project master repo. So that's a description of some work flows. Of course that's just the beginning. You can get a lot wilder than 3) if you're so inclined. And I guess a key point here is that different members can practice the above collaboration styles concurrently. It's not so much about abolishing option 1), as just enabling options 2) and 3). So why bother? Why is it worth it to take a step up to a greater degree of complexity in the software development process and tooling? In my professional projects where I have used git exclusively for over two years now, I find these to be the most significant points I have observed on my git journey. 1) SCM systems, particularly centralized ones like cvs/svn, actually discourage some developers from participation, due to the overhead of synchronization. Just look at PLplot trunk activiity. Just during the period where I've been trying to get re-engaged here over the last few weeks, I see two or three roughly completely independent whirlwinds of activity, all swirling around in the code base at the top of trunk. Everytime somebody does something, the "commit" it to trunk. Everybody's got to update, and this causes lots of rerunning cmake, rebuilding, etc. Hardly anyone is using branches. We actually used to use branches a bit back in the cvs days, but during the svn era of PLplot, I'm not sure there have been any branches used, save the python branch which I didn't manage to merge quick enough, and now it's hopelessly orphanned in the svn quagmire. With centralized SCM, the only good way to collaborate with peers, is through the central repo. And with svn branches being quite uninviting, to put it politely, people tend to collaborate through the central repo trunk (master branch in git-speak). This is obvioulsy inefficient, and it's disruptive enough that it discourages people from involvement. The way git changes this game, is by making it really really easy for a person to "live on a branch". If you fork a branch, and work on it for a while, you don't need to feel like you're getting lost, like something that fell off a fast moving train. At any time, you can just do git merge master on your topic branch, and you're tracking master, without having to inject your own, not yet ready changes onto the master. You can track master, and dvelop your topic at your own speed, and commit it to master and push it up for public consumption only when you're really ready. That means fewer "pushes" hit the project master, means other developers spend less time "integrating" the changes from others, spells less wasted time on the not-so-fun part of collaboration, and more developer focus just going into your own topic branch development work. Quite literally, git delivers a huge windfall of incentive for developers to actualy participate in an SCM managed project, instead of avoiding it. 2) Exploratory work is greatly facilitated. To me, this is perhaps the greatest benefit of using git. In cvs/svn, the only way you can "commit" your work, is to shove it into the one centralized master project repo. Even if you use a branch, it's still up there, occupying space in the permanent record. Because of this, it is actually a disincentive to do exploratory work. People get conservative over time, and only want to "commmit" stuff which is going to be a "keeper". Since people don't like to not commit their work, they tend to consolidate around only "keeper" activities, and true innovation suffers. In part, this is traceable to centralized repos. If you do something dumb, and you check it in, its up there forever. With git (and this would be true of other decentralized scms), you can do your exploratory development, check it in, obtain all the benefits of using an SCM, and *still not be commited to having others see it*. You only need to push it up when you decide it's a keeper. Sometimes you don't know that at the beginning. With git, you can do exploratory development, and then trhow it away, without ever bothering others with it, if you so choose. This is really enabling. Fantastic branching, and decentrlaized repos. Those are the things that make git such a game changer in the world of software development. IMO. Questions I could see people asking: Why not just use git-svn? If you love git so much, how about you just use git-svn? Well, I will, if that's where this leads. But with direct git hosting now an SF supported option, I thought I should just put it out there for consideration, that we could in fact, switch the whole project to git. Maybe the question is, why switch the project, when you could just use git-svn on your own? Well, git-svn ain't git. And if PLplot sticks with svn as the master repo, then we're going to keep seeing the whole developer base doing everything on trunk, because it doesn't really look like anyone's very interested in using svn branches (no surprise, since svn branching is so unappealing). Git repos are also smaller, and git is much faster. I'd like to see us switch. But I will use git-svn personally if that's my only option. What would a transition plan look like? Suppose we all try git for a bit, decide we like it, decide to switch. How does that go? There are two primary options: 1) Import the entire PLplot history, stuff that up into the SF plplot git repo as the starting point. 2) Take plplot svn trunk, check it into git, and go from there. Option 1) seems like it might be the natural/obvious choice. That said, in my professional circles, we've actually opted for 2). And been happy that way, even over the next year or two. So, personally, I'd probably just do 2) again, if others were willing to make the switch, and willing to take this shortcut. But if others were willing to make the switch only on the condition of doing it the 1) way, well, I'd be willing to help with that too. So there it is. I look forward to seeing what others have to say about this. Bottom line: Is anybody other than me interested in switching PLplot to git? -- Geoff |
From: Werner S. <sm...@ia...> - 2009-03-13 20:26:42
|
Hi Geoffrey, thanks for the explanations. I often read about git or mercury, but never really understand how this should work. Now I understand it better, still I have one question: I often commit "unfinished" work for only one reason - not to loose it. My laptop is old, the harddisk may get corrupt. I often spend some hours work and don't want to loose it. With git I can commit more often to my local repository which is fine. But if my laptop breaks these changes are also lost. You are talking about being adventurous and doing explanatory work - but are these changes only commited on my local (laptop) repository or also to the master repo (not being visible to others)? Apart from that: I personally wouldn't mind using git for PLplot development as I already use Mercury (only for local revisioned backups) and I think what you said makes sense. BUT: the last time I checked was the Windows support of git not there where it should be. A long time only a cygwin port of git was available which was practically useless if you really want to work on Windows. An although I really prefer to code in Linux or Mac OS X over then in Windows, I really think that it is important to have a Windows port of PLplot. That was also one reason why I turned away immediately when I checked git. Looks fine, but no useful Windows port? Sorry, nowadays writing cross platform code for such projects as git is should be standard. I just checked, there is now MSysGit and TortoiseGit but one can read between the lines (" although Git works very well (better, actually) on Linux or Mac. ") that it is still not there. I actually don't like it much to code in Windows (although it's 70% of my PLplot coding time), but making my life worse here doesn't help too much. So we really should make tests on Windows thoroughly if MsysGit is of any use in Windows. So in my opinion I wouldn't mind change to git, many of the things you said sounds good. But for me personally I would like to have a decent Windows port first (which may be here already) to make the transition to git also easy for the people who need to work in Windows. Regards, Werner Geoffrey Furnish wrote: > Hello all, > > Greetings after a long sabatical. > > I've been lately trying again to get re-engaged with PLplot development. One > of the first things I'm trying to get done, is to merge the python branch > that I had worked on about 15 months ago, and get that stuff onto trunk. > Then there is some more python oriented work I'd like to do from there. > > We've undertaken a few big changes on the PLplot project over the years. I > guess the biggest one of late, was the cutover to cmake. Personally, I'm > still trying to recover from that. > > In my outside-PLplot life, I and most people I work with in the professional > arena, ditched cvs/svn, and switched to git. For me, and most of my closest > professional colleagues, this switch has been both huge, and positive. > > By a huge switch, I don't so much mean to evoke worries of astronomical > catalysis barriers, as just to say that the change to git has had a really > big impact on how we do development. > > I have become so enamored with git, that I have come to view it as somewhat > arduous to work with other, lesser systems. SVN is at the top of my personal > list of "lesser" systems. Sometimes I wonder if the problem is just lack of > education on svn-ways, but I keep running across internet articles where > others lament the same difficulties as I have, so I don't think it's just me. > > Lately, in my attempts to try to get caught up with PLplot, I've actually > been using the git svn client to track our git repo. Some of you might've > noticed my triffling commits a few days ago. Those were committed using > git-svn, with no direct personal interaction with svn itself. > > 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? > > On the off chance that there are some of you who don't have a strong opinion > yet, and are willing to consider the options, I thought I'd just relate some > of my personal experiences surrounding the cutover to git. > > At my former company, Lightspeed Logic, we eventually realized that we were > outgrowing cvs. We hired more people, had more going on, and decided to > consider switching SCM's in the interest of promoting team productivity. We > did a sort of pilot study, in which people tried out both svn and git, then > we had a results comparison meeting, and ended up choosing git. > > Looking back, the one thing I would say about our efforts to compare svn > versus git, is that we were way too gracious to svn in the comparison. The > reasons we chose to switch to git instead of svn, proved to be much stronger > in retrospect than we realized at the time we made the decision. > > I really don't want to provoke any sort of major flame war here, so I enter > into a discussion of my perception of the technical stuff with some > trepidation. Fine with me if others post alternative or contradictory > viewpoints, but if it comes to that, let's just keep in mind that we're > talking about personal perceptions and experiences. > > One of the biggest things that hits newcomers to git, is the whole concept of > distributed source control. Git docs talk about peer relationships and so > on, and people sometimes wonder how you maintain any control in a git-managed > project. The git docs sometimes talk as if they're all about empowering > anti-establishment rogue coders, and this fuels the perceptions that git is > impossible to use for a project where anyone wants a sense of control. > > My answer to this is that it's just a policy decision, which is outside the > space of SCM per se. In other words, you just designate a repo as your > "official" project/company repo, and that's it. It's official because you > say so, not because it occupies any particular point in the software > collaboration interaction diagram. SF provides a technique for hosting and > communicating with that repo, so it's not at all hard for us to establish the > identify of the "master project repo". The policy needs to bbe backed up > with some relatively straightforward understandings, such as, releases will > be built from tags present in the project master repo, etc. > > The next big thing to understand about git is that it makes branching > beautiful. Others have written about the mechanisms of git branching, so I > won't go into the mechanisms. I just want to talk here about the experience, > so to speak. In git, you can fork a branch in a heartbeat. You can switch > beetween branches just as fast. Well, you might want to do a commit of your > work before switching away from a branch, but anyway its still fast. And you > can merge branches essentially willy-nilly, and git always seems to know what > you're doing. > > With cvs, you could fork a branch, work on it for a while, then merge it back > to the head. As long as you used branches that way, they worked okay. In > svn, it seems--almost unbelievably--worse. Apparently to do branch work > right in svn, you have to actually keep crib notes of your revisions for > subsequent manual merging. Frankly what I've read about it in the context of > svn has been so off-putting, that it's the main reason I haven't merged the > python branch back to trunk yet. The way I'll get it done, at this point, is > probably going to be through git (using git svn if PLplot stays svn-centric). > > With git, when you want to merge a branch, you just say git merge <other > branch>, and that merges other branch into your current branch. And this > works in all directions. You can merge topic branches into master, > quickly and easily. And you can merge the master branch into your topic > branch just as easily. This lets you "track" trunk (called master in > git-speak), easily, while maintaining as-yet unfinished topic work on a topic > branch, until it's really ready to merge. > > If I had to pick one thing about git which is truly superlative, it's the > branch management. But, there isn't just one thing about git which makes it > great. It's beyond being just merely "great" because of so many features > that all conspire together to make git a true game-changer in the world of > SCM. > > The next thing to understand about git is that it supports a wide variety of > what I call "collaboration paradigms". And I could hardly write down all the > possible work flows. Instead, let me just paint a picture of a few. > > 1) The same-old same-old cvs/svn approach, practiced with git. > > The project has a master repo, the one at SF. > Developers clone it. > They change code, check it in (git commit) to their local repo. > Developers do "git pull" to track upstream changes. > Developers do "git push" to push their changes up to the project master repo. > > 2) Individuals using branches, still mostly centralized > > The project has a master repo, the one at SF. > Developers clone it. > Developers create topic branches, do work thereupon. > Developers push their branches up to the project master repo, as well > as their changes to the master branch. > Developers occasionally merge topic branches to the master branch, and > push up this result of integration. > > 3) "Distributed development gone wild" > > The project has a master repo, the one at SF. > Developers clone it. > Developers create topic branches, do work thereupon. > Developers publish their changes to "collaboration hubs". > Other developers pull back and forth from their peers on as-interested > basis. > Eventually subteams decide something is "done enough for public > consumption". > Someone does a git co masster; git merge topic; git commit; git push origin > to make the multi-developer topic branch integrated into the master branch > and available in the project master repo. > > So that's a description of some work flows. Of course that's just the > beginning. You can get a lot wilder than 3) if you're so inclined. And I > guess a key point here is that different members can practice the above > collaboration styles concurrently. It's not so much about abolishing option > 1), as just enabling options 2) and 3). > > So why bother? Why is it worth it to take a step up to a greater degree of > complexity in the software development process and tooling? > > In my professional projects where I have used git exclusively for over two > years now, I find these to be the most significant points I have observed on > my git journey. > > 1) SCM systems, particularly centralized ones like cvs/svn, actually > discourage some developers from participation, due to the overhead of > synchronization. > > Just look at PLplot trunk activiity. Just during the period where I've been > trying to get re-engaged here over the last few weeks, I see two or three > roughly completely independent whirlwinds of activity, all swirling around in > the code base at the top of trunk. Everytime somebody does something, the > "commit" it to trunk. Everybody's got to update, and this causes lots of > rerunning cmake, rebuilding, etc. Hardly anyone is using branches. We > actually used to use branches a bit back in the cvs days, but during the svn > era of PLplot, I'm not sure there have been any branches used, save the > python branch which I didn't manage to merge quick enough, and now it's > hopelessly orphanned in the svn quagmire. With centralized SCM, the only > good way to collaborate with peers, is through the central repo. And with > svn branches being quite uninviting, to put it politely, people tend to > collaborate through the central repo trunk (master branch in git-speak). > This is obvioulsy inefficient, and it's disruptive enough that it discourages > people from involvement. > > The way git changes this game, is by making it really really easy for a > person to "live on a branch". If you fork a branch, and work on it for a > while, you don't need to feel like you're getting lost, like something that > fell off a fast moving train. At any time, you can just do git merge master > on your topic branch, and you're tracking master, without having to inject > your own, not yet ready changes onto the master. You can track master, and > dvelop your topic at your own speed, and commit it to master and push it up > for public consumption only when you're really ready. > > That means fewer "pushes" hit the project master, means other developers > spend less time "integrating" the changes from others, spells less wasted > time on the not-so-fun part of collaboration, and more developer focus just > going into your own topic branch development work. > > Quite literally, git delivers a huge windfall of incentive for developers to > actualy participate in an SCM managed project, instead of avoiding it. > > 2) Exploratory work is greatly facilitated. > > To me, this is perhaps the greatest benefit of using git. In cvs/svn, the > only way you can "commit" your work, is to shove it into the one centralized > master project repo. Even if you use a branch, it's still up there, > occupying space in the permanent record. Because of this, it is actually a > disincentive to do exploratory work. People get conservative over time, and > only want to "commmit" stuff which is going to be a "keeper". Since people > don't like to not commit their work, they tend to consolidate around only > "keeper" activities, and true innovation suffers. In part, this is traceable > to centralized repos. If you do something dumb, and you check it in, its up > there forever. > > With git (and this would be true of other decentralized scms), you can do > your exploratory development, check it in, obtain all the benefits of using > an SCM, and *still not be commited to having others see it*. You only need > to push it up when you decide it's a keeper. Sometimes you don't know that > at the beginning. > > With git, you can do exploratory development, and then trhow it away, > without ever bothering others with it, if you so choose. This is really > enabling. > > Fantastic branching, and decentrlaized repos. Those are the things that make > git such a game changer in the world of software development. IMO. > > Questions I could see people asking: > > Why not just use git-svn? If you love git so much, how about you just use > git-svn? > > Well, I will, if that's where this leads. But with direct git hosting now an > SF supported option, I thought I should just put it out there for > consideration, that we could in fact, switch the whole project to git. Maybe > the question is, why switch the project, when you could just use git-svn on > your own? > > Well, git-svn ain't git. And if PLplot sticks with svn as the master repo, > then we're going to keep seeing the whole developer base doing everything on > trunk, because it doesn't really look like anyone's very interested in using > svn branches (no surprise, since svn branching is so unappealing). > > Git repos are also smaller, and git is much faster. > > I'd like to see us switch. But I will use git-svn personally if that's my > only option. > > > What would a transition plan look like? Suppose we all try git for a bit, > decide we like it, decide to switch. How does that go? > > There are two primary options: > > 1) Import the entire PLplot history, stuff that up into the SF plplot git > repo as the starting point. > > 2) Take plplot svn trunk, check it into git, and go from there. > > Option 1) seems like it might be the natural/obvious choice. That said, in > my professional circles, we've actually opted for 2). And been happy that > way, even over the next year or two. > > So, personally, I'd probably just do 2) again, if others were willing to make > the switch, and willing to take this shortcut. But if others were willing to > make the switch only on the condition of doing it the 1) way, well, I'd be > willing to help with that too. > > So there it is. I look forward to seeing what others have to say about > this. Bottom line: Is anybody other than me interested in switching PLplot > to git? > > -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria DVR-Nr: 0005886 email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Geoffrey F. <Geo...@at...> - 2009-03-13 20:58:56
|
Werner Smekal writes: > I often commit "unfinished" work for only one reason - not to loose it. > My laptop is old, the harddisk may get corrupt. I often spend some hours > work and don't want to loose it. With git I can commit more often to my > local repository which is fine. But if my laptop breaks these changes > are also lost. You are talking about being adventurous and doing > explanatory work - but are these changes only commited on my local > (laptop) repository or also to the master repo (not being visible to > others)? Well, either is possible. Personally I would like to avoid pushing things into the project master repo until they're "ready". So if I were trying to have a backup, as you describe, what I would suggest would be to set up another git repo on another physical machine, and push my intermediate work to that repo. With suitable configuration, you could say "git push backup", where backup was a git id for a network accessible repo on another machine. If you said "git push origin", which is the same as saying "git push", then your commits would be propagated to the project master repo. If those changes were on a branch, then you would be updating the branch in the project master repo, with your incremental work. That would be better (meaning, lower impact on others), than pushing intermediate work in on trunk/master, but it still represents pushing things into the project master repo, when all you're really trying to do is achieve some redundancy as a guard against system failure. In my opinion, better to define "backup" as a git alias for some machine you control, network accessible to you, in your home or office network, and then use "git push backup" as a way to do this sort of safety-net stuff. Bottom line, git provides more, and more sophisticated options for collaboration (which can also mean, ways of collaborating with yourself), and these can avoid going through the project master. To me, this is a very big benefit. But, bottom line, git does not enforce a limited set of options. It's more like the superlative tool for SCM, and leaves it to you how you want to use it. > Apart from that: I personally wouldn't mind using git for PLplot > development as I already use Mercury (only for local revisioned backups) > and I think what you said makes sense. BUT: the last time I checked was > the Windows support of git not there where it should be. A long time > only a cygwin port of git was available which was practically useless if > you really want to work on Windows. An although I really prefer to code > in Linux or Mac OS X over then in Windows, I really think that it is > important to have a Windows port of PLplot. That was also one reason why > I turned away immediately when I checked git. Looks fine, but no > useful Windows port? Sorry, nowadays writing cross platform code for > such projects as git is should be standard. > > I just checked, there is now MSysGit and TortoiseGit but one can read > between the lines (" although Git works very well (better, actually) on > Linux or Mac. ") that it is still not there. I actually don't like it > much to code in Windows (although it's 70% of my PLplot coding time), > but making my life worse here doesn't help too much. So we really should > make tests on Windows thoroughly if MsysGit is of any use in Windows. > > So in my opinion I wouldn't mind change to git, many of the things you > said sounds good. But for me personally I would like to have a decent > Windows port first (which may be here already) to make the transition to > git also easy for the people who need to work in Windows. I understand, and agree. It is obvious that the Windows work is important to PLplot. So I also would want to hear that our various team members who work regularly on windows, have a git option which is acceptable to them. I personally do not touch windows. [<sheepish smirk> I should write a book someday, about what happens to corporate IT admins who try to force me to use windows.] I keep telling myself I should set up a cross tool chain on my Linux boxes, and practice running cross-tool builds through Wine. But I never get around to it. Nevertheless, my personal habits are obviously not representative of the whole PLplot team. So I do agree and believe, that we would need agreement from those PLplot core developers who do do development on Windows, that the git situation has reached an acceptable state for them. I can't contribute to that evaluation, except to answer questions about how git works, which I am happy to do. -- Geoff |
From: Alan W. I. <ir...@be...> - 2009-03-13 22:09:07
|
On 2009-03-13 10:17-0600 Geoffrey Furnish wrote: > [...]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. Hi Geoffrey: Thanks for your thoughtful and thought-provoking post. However, although I normally tend to be an early adopter, I don't think we should move to git at this time. Reasons in context below. > > Here's the SF page relating to project git support: > > http://apps.sourceforge.net/trac/sourceforge/wiki/Git > > [..]One of the biggest things that hits newcomers to git, is the whole concept of > distributed source control. Git docs talk about peer relationships and so > on, and people sometimes wonder how you maintain any control in a git-managed > project. The git docs sometimes talk as if they're all about empowering > anti-establishment rogue coders, and this fuels the perceptions that git is > impossible to use for a project where anyone wants a sense of control. > > My answer to this is that it's just a policy decision, which is outside the > space of SCM per se. In other words, you just designate a repo as your > "official" project/company repo, and that's it. It's official because you > say so, not because it occupies any particular point in the software > collaboration interaction diagram. SF provides a technique for hosting and > communicating with that repo, so it's not at all hard for us to establish the > identify of the "master project repo". The policy needs to bbe backed up > with some relatively straightforward understandings, such as, releases will > be built from tags present in the project master repo, etc. Fair enough. > > The next big thing [...] > which is truly superlative, it's the > branch management. I believe you, but see my comments about branches below. > The next thing to understand about git is that it supports a wide variety of > what I call "collaboration paradigms". And I could hardly write down all the > possible work flows. Instead, let me just paint a picture of a few. > > 1) The same-old same-old cvs/svn approach, practiced with git. > > 2) Individuals using branches, still mostly centralized > > 3) "Distributed development gone wild" > > The project has a master repo, the one at SF. > Developers clone it. > Developers create topic branches, do work thereupon. > Developers publish their changes to "collaboration hubs". > Other developers pull back and forth from their peers on as-interested > basis. > Eventually subteams decide something is "done enough for public > consumption". > Someone does a git co masster; git merge topic; git commit; git push origin > to make the multi-developer topic branch integrated into the master branch > and available in the project master repo. > > So that's a description of some work flows. Of course that's just the > beginning. You can get a lot wilder than 3) if you're so inclined. And I > guess a key point here is that different members can practice the above > collaboration styles concurrently. It's not so much about abolishing option > 1), as just enabling options 2) and 3). >From my observations of projects that use git (such as the Intel X driver stack which includes at least the kernel, drm, mesa, X server and the Intel X driver), (3) is a huge issue. It appears each one of those stack components has a whole variety of possible git version possibilities so a lot of time is wasted in testing trying to figure out which git version to use for each component. I have a X instability problem for my Intel hardware, but I have largely given up reporting it because the X Intel developers appear to be off in their own land working with inconsistent bits and pieces which nobody else tests. (I fully expect this situation to improve once the pace of Intel X development slows down, but I have been saying that for the past year, and there is still no end in sight with more and more features and no fix for instability issues.) Carl Worth (a well-respected X developer who works for Intel and who is keen as mustard on git) is having big problems with this issue just trying to sort out what will go into their next release. If he is having trouble sorting out the git bits and pieces for the X intel stack, there is little hope for the rest of us mere mortals! That stack of software is obviously an extreme case of git development gone wild, and I doubt PLplot development will never be that wild. Nevertheless, it is a concern if PLplot moves to git because even now we have trouble getting users and developers to report back the exact version of PLplot they were using when they give bug reports, and it appears the possibility of additional git versions would just exacerbate that problem. > > So why bother? Why is it worth it to take a step up to a greater degree of > complexity in the software development process and tooling? > > In my professional projects where I have used git exclusively for over two > years now, I find these to be the most significant points I have observed on > my git journey. > > 1) SCM systems, particularly centralized ones like cvs/svn, actually > discourage some developers from participation, due to the overhead of > synchronization. > > Just look at PLplot trunk activiity. Just during the period where I've been > trying to get re-engaged here over the last few weeks, I see two or three > roughly completely independent whirlwinds of activity, all swirling around in > the code base at the top of trunk. Everytime somebody does something, the > "commit" it to trunk. Everybody's got to update, and this causes lots of > rerunning cmake, rebuilding, etc. For a large project that might be an issue, but a rebuild of PLplot takes very little time at all (especially with CMake). Also, the various components of PLplot are really nicely separated with few side effects so you really have to work at it to mess up others who are working on some different component of PLplot on the svn trunk. Of course, if two people are working on, e.g., qt together, they could mess each other up, but I personally like the implied build discipline demanded of all our developers by working on the trunk together. Thus, there was little point to work on qt on a branch. Similarly, I had no interest in working on the recent qsastime stuff (still on-going by the way with more leap seconds functionality to come) on a branch. The point is, our build system is flexible enough to easily work around most issues introduced by working together on the trunk version. In practice, our de facto development on svn trunk has worked out well with trunk build breakages for default configurations being extremly rare, and when they do exist, short lived. > Hardly anyone is using branches. We > actually used to use branches a bit back in the cvs days, but during the svn > era of PLplot, I'm not sure there have been any branches used, save the > python branch which I didn't manage to merge quick enough, and now it's > hopelessly orphanned in the svn quagmire. With centralized SCM, the only > good way to collaborate with peers, is through the central repo. And with > svn branches being quite uninviting, to put it politely, people tend to > collaborate through the central repo trunk (master branch in git-speak). > This is obvioulsy inefficient, and it's disruptive enough that it discourages > people from involvement. I admit my bias here. I am just not that convinced of the desireability of branches for most PLplot code development. Let's face it, a lot of our development focusses on language bindings, examples, and device drivers and not the core library. Thus, the natural separation of most of those periperal components allows us to develop together in the trunk version without messing each other up rather than separately on branches. Of course, if a change is really disruptive, it should be done on a branch. Your historical development of our dynamic device functionality is a good case in point. It is possible your recent development of a plframe GUI capability for python also belongs in that category, but the question there is obfuscated by a lot of cruft in our python bindings and examples, which I probably think belongs to you and vice versa so it might have been better to do a cleanout of the old cruft first, then do that development on the trunk. > > The way git changes this game, is by making it really really easy for a > person to "live on a branch". If you fork a branch, and work on it for a > while, you don't need to feel like you're getting lost, like something that > fell off a fast moving train. At any time, you can just do git merge master > on your topic branch, and you're tracking master, without having to inject > your own, not yet ready changes onto the master. You can track master, and > dvelop your topic at your own speed, and commit it to master and push it up > for public consumption only when you're really ready. > > That means fewer "pushes" hit the project master, means other developers > spend less time "integrating" the changes from others, spells less wasted > time on the not-so-fun part of collaboration, and more developer focus just > going into your own topic branch development work. > > Quite literally, git delivers a huge windfall of incentive for developers to > actualy participate in an SCM managed project, instead of avoiding it. I realize my bias on this subject so I would be willing to conceed this point. Everybody tells me that once they have tried git, they do not ever want to move back to subversion. The problem for me is I haven't tried git so I don't miss it a bit. :-) > > 2) Exploratory work is greatly facilitated. > > To me, this is perhaps the greatest benefit of using git. In cvs/svn, the > only way you can "commit" your work, is to shove it into the one centralized > master project repo. Even if you use a branch, it's still up there, > occupying space in the permanent record. Because of this, it is actually a > disincentive to do exploratory work. People get conservative over time, and > only want to "commmit" stuff which is going to be a "keeper". Since people > don't like to not commit their work, they tend to consolidate around only > "keeper" activities, and true innovation suffers. In part, this is traceable > to centralized repos. If you do something dumb, and you check it in, its up > there forever. > > With git (and this would be true of other decentralized scms), you can do > your exploratory development, check it in, obtain all the benefits of using > an SCM, and *still not be commited to having others see it*. You only need > to push it up when you decide it's a keeper. Sometimes you don't know that > at the beginning. > > With git, you can do exploratory development, and then trhow it away, > without ever bothering others with it, if you so choose. This is really > enabling. > > Fantastic branching, and decentrlaized repos. Those are the things that make > git such a game changer in the world of software development. IMO. Excellent points. git sounds like a paradigm shift that would shake up PLplot development considerably in a positive way. > [...]What would a transition plan look like? Suppose we all try git for a bit, > decide we like it, decide to switch. How does that go? > > There are two primary options: > > 1) Import the entire PLplot history, stuff that up into the SF plplot git > repo as the starting point. > > 2) Take plplot svn trunk, check it into git, and go from there. > > Option 1) seems like it might be the natural/obvious choice. That said, in > my professional circles, we've actually opted for 2). And been happy that > way, even over the next year or two. I am convinced our code history is worth preserving. That allows us to delete unused code now in confidence that if we ever need it back we can easily get it from the repo. (For example, I am going to propose removing the currently unused parts of the sys directory tree in the near future because I KNOW we can get any of it back from svn.) Furthermore, our history helps us to keep track of licensing issues which is really important for a open-source project. Finally, our project is one of the oldest open-source projects around so it would be a shame to delete all that history. So to my mind approach (1) is an absolute requirement, and approach (2) would be a showstopper. I felt so strongly about this issue, that I put in long hours on the conversion from cvs to svn (including extensive automatic checks of every separate commit message) just to make sure our history was completely preserved. I will demand similar care for any proposed svn to git conversion project, but I warn such care is going to take lots of effort by anybody who volunteers to do that conversion work. In any case, I think we should put off this decision at least for a year. My idea is to let other projects be the SF guinea pigs to work out all the bugs in the freshly minted SF git support as well as to improve the tools for conversion of a project (including all its history) from svn to git. In sum, I am against moving to git for now, but we should consider this possibility again in the future (say when a majority of our developers are enthused about git from personal experience with it for other projects, and when someone steps forward to do the svn to git conversion work along with the hard part which is the required detailed checking of same). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Geoffrey F. <Geo...@at...> - 2009-03-14 05:18:07
|
Alan W. Irwin writes: > On 2009-03-13 10:17-0600 Geoffrey Furnish wrote: > > [...]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. > > Thanks for your thoughtful and thought-provoking post. However, although I > normally tend to be an early adopter, I don't think we should move to git at > this time. > > Reasons in context below. > [...] > > > > The next thing to understand about git is that it supports a wide > > variety of what I call "collaboration paradigms". And I could hardly > > write down all the possible work flows. Instead, let me just paint a > > picture of a few. > > > > 1) The same-old same-old cvs/svn approach, practiced with git. > > > > 2) Individuals using branches, still mostly centralized > > > > 3) "Distributed development gone wild" > > > > The project has a master repo, the one at SF. > > Developers clone it. > > Developers create topic branches, do work thereupon. > > Developers publish their changes to "collaboration hubs". > > Other developers pull back and forth from their peers on as-interested > > basis. > > Eventually subteams decide something is "done enough for public > > consumption". > > Someone does a git co masster; git merge topic; git commit; git push > > origin to make the multi-developer topic branch integrated into the > > master branch and available in the project master repo. > > > > So that's a description of some work flows. Of course that's just the > > beginning. You can get a lot wilder than 3) if you're so inclined. And > > I guess a key point here is that different members can practice the > > above collaboration styles concurrently. It's not so much about > > abolishing option 1), as just enabling options 2) and 3). > > From my observations of projects that use git (such as the Intel X driver > stack which includes at least the kernel, drm, mesa, X server and the > Intel X driver), (3) is a huge issue. It appears each one of those stack > components has a whole variety of possible git version possibilities so a > lot of time is wasted in testing trying to figure out which git version to > use for each component. I have a X instability problem for my Intel > hardware, but I have largely given up reporting it because the X Intel > developers appear to be off in their own land working with inconsistent > bits and pieces which nobody else tests. (I fully expect this situation > to improve once the pace of Intel X development slows down, but I have > been saying that for the past year, and there is still no end in sight > with more and more features and no fix for instability issues.) Carl Worth > (a well-respected X developer who works for Intel and who is keen as > mustard on git) is having big problems with this issue just trying to sort > out what will go into their next release. If he is having trouble sorting > out the git bits and pieces for the X intel stack, there is little hope > for the rest of us mere mortals! I hope you don't mind a couple of clarifying questions. Are you saying that there is trouble with different versions of git? Or are you saying there are several separate pieces of software, each with several developers, each publishing their own publicly accessible git repos, so that end users are bewildered with trying to figure out what to pull from where to assemble all the pieces of a working system? At first I thought you were saying the former, but after rereading your comments several times, I'm starting to think you are saying the later. If the later, well, I think it's a bit hyperbolic to apply it to PLplot. What I imagine for PLplot, if we were to switch to git, is that we would continue to maintain a clear "master repo" (the one hosted at SF). We would put tags on that repo, do release builds from only tags that are in that repo, and so on. Users would be expected to take file releases, or at least be working with their origin set to our master project repo, if they want help from the list. I could further imagine that developers might advertise "collaboration hubs" amongst themselves. Not meaning private e-mail only. Plplot-devel would be fine. But the point is, X says to Y, "Pull my branch uvw from my publicly accessible git collab hub at git://wherever/plplot", and Y says "Great, now feetch my further updates from git://elsewhere/plplot". When X and Y are mutually satisfied, one of them pushes it up. Meanwhile, develper Z might be following a more clasic work flow of just cloning the project master, working on the master branch, and pushing up when ready. The two models are not mutually exclusvie. In all cases, we're talking about a "software stack" of just one git module: plplot. So the picemeil assemblage problem you describe with the Intel X driver project seems like a distant worry for a git-based PLplot future, to me. > That stack of software is obviously an extreme case of git development > gone wild, and I doubt PLplot development will never be that wild. > Nevertheless, it is a concern if PLplot moves to git because even now we > have trouble getting users and developers to report back the exact version > of PLplot they were using when they give bug reports, and it appears the > possibility of additional git versions would just exacerbate that problem. I think I agree, except for the extent of my worry about this. Every user can report their origin, and the git commit identifier. I would suggest that unless their origin is our SF-hosted repo, they don't have a reasonable expectation of getting much help from the PLplot core team. If one of us were to publish our own PLplot git repo, and some user had issues with sometehing they pulled from that, then it should be pretty clear they need to contact that same developer for support. The PLplot team should be able to feel pretty relaxed about communicating to users that if they want help, they need to be asking about a branch that is available in the project master repo, if they want support on list. That doesn't seem at all unreasonable to me, nor would I expect it to be off-putting or unexpected by the general user community. > > 1) SCM systems, particularly centralized ones like cvs/svn, actually > > discourage some developers from participation, due to the overhead of > > synchronization. > > > > Just look at PLplot trunk activiity. Just during the period where I've > > been trying to get re-engaged here over the last few weeks, I see two or > > three roughly completely independent whirlwinds of activity, all > > swirling around in the code base at the top of trunk. Everytime > > somebody does something, the "commit" it to trunk. Everybody's got to > > update, and this causes lots of rerunning cmake, rebuilding, etc. > > For a large project that might be an issue, but a rebuild of PLplot takes > very little time at all (especially with CMake). Also, the various > components of PLplot are really nicely separated with few side effects so > you really have to work at it to mess up others who are working on some > different component of PLplot on the svn trunk. Not to be contrarion, or mean-spirited, but I should just point out that from my perspective, PLplot is pretty "messed up" right now. And has been for a very very long time. I have two different code bases in my professional life that link to PLplot. Both of them are locked into years-old versions of PLplot. About a year ago I made the mistake of bumping one of them up to a modern PLplot release, and then got flooded by users of my code reporting segfaults which took down the whole application. The problems are mostly apparently something having to do with the Tk widget (plframe). But the point is, it's been broken for many many releases, it prevents me from updating to trunk on two professional projects until I find and fix the bug(s). I am committed to doing this, as time allows, and will propagate the fixes to the PLplot repo (svn or perhaps a git repo if we can get there) when I have them. I am just trying to drive the point that the current situation with PLplot is not entirely ducky. There are long standing problems that need fixing. > Of course, if two people are working on, e.g., qt together, they could > mess each other up, but I personally like the implied build discipline > demanded of all our developers by working on the trunk together. To me, this is more distractive than helpful. > Thus, there was little point to work on > qt on a branch. Similarly, I had no interest in working on the recent > qsastime stuff (still on-going by the way with more leap seconds > functionality to come) on a branch. The point is, our build system is > flexible enough to easily work around most issues introduced by working > together on the trunk version. Distraction is the big issue I see. No one working style will ever suit everyone, and I am not really directly trying to say "Alan, you should work on a branch". But what I am trying to say is that some people would choose to work on a branch a lot more, if the SCM system was better with branches. Svn is winning a reputation as a particularly weak contender for some working paradigms that some people like a lot. Other people are happy with it. What I see as being significant about git is that it supports more collaboration paradigms effectively, without forcing you to use just one limited one. Some people may just not like the perceived complexity, but there are simple working styles that are well supported with git, as well as much more sophisticated working styles that are also supported well by git. Unfortunately, statements like this cannot be made about svn. > In practice, our de facto development on svn trunk has worked out well with > trunk build breakages for default configurations being extremly rare, and > when they do exist, short lived. It's great to be associated with a project with so much vitality. But I do think it would help if things hit the master/trunk in more complete shape when they first showed up. "Fewer, bigger pushes" we would say in git-speak. > > Hardly anyone is using branches. We actually used to use branches a bit > > back in the cvs days, but during the svn era of PLplot, I'm not sure > > there have been any branches used, save the python branch which I didn't > > manage to merge quick enough, and now it's hopelessly orphanned in the > > svn quagmire. With centralized SCM, the only good way to collaborate > > with peers, is through the central repo. And with svn branches being > > quite uninviting, to put it politely, people tend to collaborate through > > the central repo trunk (master branch in git-speak). This is obvioulsy > > inefficient, and it's disruptive enough that it discourages people from > > involvement. > > I admit my bias here. I am just not that convinced of the desireability of > branches for most PLplot code development. Let's face it, a lot of our > development focusses on language bindings, examples, and device drivers and > not the core library. Thus, the natural separation of most of those > periperal components allows us to develop together in the trunk version > without messing each other up rather than separately on branches. A huge fraction of the commits (this is my subjective observation/evaluation) is hitting in the area of the cmake config files, which affect everyone. Perhaps it usually works. But I'm just saying, there's no reason for that stuff to be on master/trunk till it's "more done". The reason for the current practice is, I think, largely driven by the weakness of svn, rather than by inherent superiority of the software development process practiced in this manner. > Of course, if a change is really disruptive, it should be done on a > branch. Your historical development of our dynamic device functionality > is a good case in point. It is possible your recent development of a > plframe GUI capability for python also belongs in that category, but the > question there is obfuscated by a lot of cruft in our python bindings and > examples, which I probably think belongs to you and vice versa so it might > have been better to do a cleanout of the old cruft first, then do that > development on the trunk. Part of the reason I started the python branch in PLplot/svn, was, well, err, I guess a couple: 1) I was ridiculously naive about svn. I thought it would work better for branch-based development. Boy did I get "educated". 2) I knew I would be diddling with the build system, and I saw no reason to foist that upon others till I had it worked out better. I am very comfortable with that call, in retrospect. When I do merge that work into trunk in the coming days, I'm probably still going to need help from others, but at least you guys missed all the thrashing along the way up until now. That's one of my big points here. The whole group doesn't need to have my (or anyone else's) thrashing in their face. We just need the done stuff. Sometimes getting done requires help, and thus we need ways to collaborate. Checking in partially working stuff on the trunk of the master project repo is one way to pass work to collaborators. But it also pushes the same work in progress (WIP) materials into the update/checkout path for others who *don't* have interest in collaborating on that particular thing. Branches, and outside-of-the-project-master-repo, collaboration schemes, as offered by git, provide a way around these disruptions to the rest of the team. > I realize my bias on this subject so I would be willing to conceed this > point. Everybody tells me that once they have tried git, they do not > ever want to move back to subversion. The problem for me is I haven't tried > git so I don't miss it a bit. :-) I totally understand. One thing I'm looking for here in this thread, is to see if others are interested, and if so, let's identify what we could do to help people get the exposure they would need to feel good about making a decision. Certianly one thing we need, is to hear from people who develop on Windows regularly, if they can live with any of the git clients for Windows. But the group will surely have other requirements that would factor into a decision to switch, and I would like to learn what these other requirements might be. Understanding work flows is probably another area where people have questions. And may or may not feel they know how to state the questions. > > [...]What would a transition plan look like? Suppose we all try git for > > a bit, decide we like it, decide to switch. How does that go? > > > > There are two primary options: > > > > 1) Import the entire PLplot history, stuff that up into the SF plplot git > > repo as the starting point. > > > > 2) Take plplot svn trunk, check it into git, and go from there. > > > > Option 1) seems like it might be the natural/obvious choice. That said, > > in my professional circles, we've actually opted for 2). And been happy > > that way, even over the next year or two. > > I am convinced our code history is worth preserving. That allows us to > delete unused code now in confidence that if we ever need it back we can > easily get it from the repo. (For example, I am going to propose removing > the currently unused parts of the sys directory tree in the near future > because I KNOW we can get any of it back from svn.) Furthermore, our > history helps us to keep track of licensing issues which is really > important for a open-source project. Finally, our project is one of the > oldest open-source projects around so it would be a shame to delete all > that history. So to my mind approach (1) is an absolute requirement, and > approach (2) would be a showstopper. I felt so strongly about this issue, > that I put in long hours on the conversion from cvs to svn (including > extensive automatic checks of every separate commit message) just to make > sure our history was completely preserved. I will demand similar care for > any proposed svn to git conversion project, but I warn such care is going > to take lots of effort by anybody who volunteers to do that conversion > work. In the professional cases I mentioned above, we did not "sacrifie history". We just agreed that if we needed history prior to the cutover date, we'd go back to the old SCM to get it. We didn't throw out the old SCM (which was cvs), and rm -rf * it. We held on to it, and used it if necessary. Our team was satisfied with that. Like you, I value the history, and if we switched to git, and used option 1), I would definitely also require that SVN stay "live". But if you realized that option already, and still mean you require the old history to be preserved in the new repo, so that you would never have to type svn again, well, it is definitely possilbe to achieve that, and I'm certainly not opposed to it. > In any case, I think we should put off this decision at least for a > year. !!! Yikes. Svn is killing me! Okay, slight exageration. But I would like to understand your requirements in detail. That would help me assess the work involved in satisfying them. If your requirements knock me over, then yeah, waiting a year for others to hammer on the svn to git import system might turn out to be the best option. But I've migrated stuff from cvs into git, and been happy with the result, and have used git exclusively for two years now, with absolutely no regrets. So rather than just glibly putting it off for a year, I'd rather understand what you feel is essential before you could be convinced. And I'd rather not make a decision on a timeline/goal, until I see what your list looks like. > My idea is to let other projects be the SF guinea pigs to work out > all the bugs in the freshly minted SF git support as well as to improve > the tools for conversion of a project (including all its history) from svn > to git. > > In sum, I am against moving to git for now, but we should consider this > possibility again in the future (say when a majority of our developers are > enthused about git from personal experience with it for other projects, and > when someone steps forward to do the svn to git conversion work along with > the hard part which is the required detailed checking of same). Mmm. Are there ways we could explore the potential of git directly on this project? I'll bet there are. If there's interest, there surely is a way to dabble and test the waters. I'm not talking about cutting over from svn to git in some sort of a whiplash inducing sudden irreversible transaction. Rather, I'm looking for ways we could keep svn as the project maste rrepo for now, but test the waters a bit, shall we say, with git. If I found a way to publish a PLplot git repo with something new in it, is there anyone who would be willing to pull it and give it a whirl? I don't actually have a good way to do that right now, outside of SF. My current employer is not into providing web services for extracurricular activities, so to speak. So I'll have to think a bit about how I might do that. Cheers, -- Geoff |
From: Alan W. I. <ir...@be...> - 2009-03-14 07:58:25
|
On 2009-03-13 23:17-0600 Geoffrey Furnish wrote: > Alan W. Irwin writes: > > From my observations of projects that use git (such as the Intel X driver > > stack which includes at least the kernel, drm, mesa, X server and the > > Intel X driver), (3) is a huge issue. > > [...] Carl Worth > > (a well-respected X developer who works for Intel and who is keen as > > mustard on git) is having big problems with this issue just trying to sort > > out what will go into their next release. If he is having trouble sorting > > out the git bits and pieces for the X intel stack, there is little hope > > for the rest of us mere mortals! > > [...]are you saying there are > several separate pieces of software, each with several developers, each > publishing their own publicly accessible git repos, so that end users are > bewildered with trying to figure out what to pull from where to assemble all > the pieces of a working system? Yep. > [if so] I think it's a bit hyperbolic to apply it to PLplot. More than a bit as I hope I made clear (see the first sentence of what you quoted from me below). > [...] So the picemeil assemblage problem you describe with the Intel X driver > project seems like a distant worry for a git-based PLplot future, to me. Largely, agreed, see the next quoted sentence. >> That stack of software is obviously an extreme case of git development >> gone wild, and I doubt PLplot development will never be that wild. >> Nevertheless, it is a concern if PLplot moves to git because even now we >> have trouble getting users and developers to report back the exact version >> of PLplot they were using when they give bug reports, and it appears the >> possibility of additional git versions would just exacerbate that problem. > I think I agree, except for the extent of my worry about this. Every user > can report their origin, and the git commit identifier. I would suggest > that > unless their origin is our SF-hosted repo, they don't have a reasonable > expectation of getting much help from the PLplot core team. > If one of us were to publish our own PLplot git repo, and some user had > issues with sometehing they pulled from that, then it should be pretty clear > they need to contact that same developer for support. The PLplot team > should > be able to feel pretty relaxed about communicating to users that if they > want > help, they need to be asking about a branch that is available in the project > master repo, if they want support on list. > That doesn't seem at all unreasonable to me, nor would I expect it to be > off-putting or unexpected by the general user community. That seems okay in theory, but in the admittedly extreme case of X that is not working out at all well in practice. Basically git allows complete freedom of development which is all very nice, but my point is there are also some potential drawbacks to be concerned about such as fragmentation of the development and testing effort that turns off many of those (like me in the X situation) that like to help out with bug reports. > > > > 1) SCM systems, particularly centralized ones like cvs/svn, actually > > > discourage some developers from participation, due to the overhead of > > > synchronization. > > > > > > Just look at PLplot trunk activiity. Just during the period where I've > > > been trying to get re-engaged here over the last few weeks, I see two or > > > three roughly completely independent whirlwinds of activity, all > > > swirling around in the code base at the top of trunk. Everytime > > > somebody does something, the "commit" it to trunk. Everybody's got to > > > update, and this causes lots of rerunning cmake, rebuilding, etc. > > > > For a large project that might be an issue, but a rebuild of PLplot takes > > very little time at all (especially with CMake). Also, the various > > components of PLplot are really nicely separated with few side effects so > > you really have to work at it to mess up others who are working on some > > different component of PLplot on the svn trunk. > > [...]I have two different code bases in my professional life that link to PLplot. > Both of them are locked into years-old versions of PLplot. About a year ago > I made the mistake of bumping one of them up to a modern PLplot release, and > then got flooded by users of my code reporting segfaults which took down the > whole application. > > The problems are mostly apparently something having to do with the Tk widget > (plframe). But the point is, it's been broken for many many releases, it > prevents me from updating to trunk on two professional projects until I find > and fix the bug(s). I agree with you this far; we did not have deep enough testing until the second to last release when I resurrected a fairly comprehensive interactive test script (you can now run this with "make test_interactive" in the installed examples tree). That test script turned up the segfaults for Tk plframe for the first time to my knowledge, but it would have been better if you had communicated knowledge of those segfaults much earlier to me or any of the other active developers. (I am not sure we could have done anything to fix the problem, but at least we could have warned users, turned Tk OFF by default, etc. until you found a fix.) > > I am committed to doing this (find and fix the Tk plframe bugs), as time allows, and will propagate the fixes to > the PLplot repo (svn or perhaps a git repo if we can get there) when I have > them. Good. That is the best solution since you and Maurice are essentially the only developers of Tk plframe and thus you have the best chance by far of all the PLplot developers to fix it again. I won't answer the rest of your comments in detail because I think you already know from my previous comments where I stand. However, I will comment on your general observation which is that the current PLplot has rather active development. That observation pleased me a lot since I think that is a sign of a really healthy project. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Hezekiah M. C. <hc...@at...> - 2009-03-14 15:51:34
|
On Sat, Mar 14, 2009 at 1:17 AM, Geoffrey Furnish <Geo...@at...> wrote: > Alan W. Irwin writes: > > My idea is to let other projects be the SF guinea pigs to work out > > all the bugs in the freshly minted SF git support as well as to improve > > the tools for conversion of a project (including all its history) from svn > > to git. > > > > In sum, I am against moving to git for now, but we should consider this > > possibility again in the future (say when a majority of our developers are > > enthused about git from personal experience with it for other projects, and > > when someone steps forward to do the svn to git conversion work along with > > the hard part which is the required detailed checking of same). > > Mmm. Are there ways we could explore the potential of git directly on this > project? I'll bet there are. If there's interest, there surely is a way to > dabble and test the waters. To provide a data point on this, I do all of my PLplot development through a git clone of the PLplot Subversion trunk. New revisions are pulled from the Subversion repository each night. The repository can be viewed through a web interface here: http://0ok.org/git/?p=plplot-mirror.git;a=summary While this particular repository only contains the trunk, it does have the full PLplot history from Subversion. For an example, see here for the history of include/plplot.h (note that this is running on a shared web hosting service, so it may take 15-45 seconds to load): http://0ok.org/git/?p=plplot-mirror.git;a=history;f=include/plplot.h;h=HEAD;hb=HEAD The first revision available for that file is: "1992-05-20 furnish Initial checkin of the whole PLPLOT project." There are faster web interfaces than the one I am using on the site above, but I have not bothered with them since this site is in place for my own use. Setting up this git mirror was very simple, as git comes with tools to do the history cloning work for you. With a few extra steps beyond the ones I took, one can even provide full name and email aliases for the Subversion usernames currently listed. The only reason that I didn't clone more branches than the PLplot Subversion trunk is that, at the time I created this repository, I didn't have a use for them. Again, the same git <-> Subversion interaction tools support automatic import of history for each Subversion branch in to git. This git repository is not currently publicly available. If there is some interest from the PLplot developers in testing the git waters though I can change it to allow read-only checkouts. I do not want to create any bad blood here though, so if there is any significant opposition I will not do so. Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science |
From: Maurice L. <mj...@br...> - 2009-03-16 03:30:58
|
On Friday, March 13, 2009 at 23:17:57 (-0600) Geoffrey Furnish writes: > I have two different code bases in my professional life that link to PLplot. > Both of them are locked into years-old versions of PLplot. About a year ago > I made the mistake of bumping one of them up to a modern PLplot release, and > then got flooded by users of my code reporting segfaults which took down the > whole application. > > The problems are mostly apparently something having to do with the Tk widget > (plframe). But the point is, it's been broken for many many releases, it > prevents me from updating to trunk on two professional projects until I find > and fix the bug(s). > > I am committed to doing this, as time allows, and will propagate the fixes to > the PLplot repo (svn or perhaps a git repo if we can get there) when I have > them. > > I am just trying to drive the point that the current situation with PLplot is > not entirely ducky. There are long standing problems that need fixing. I'm just quoting a portion of this thread in order to make a couple of quick comments. There's no substitute for putting in the time, and there both you and I have faltered over the last few years (understandably, given our other priorities). Heck, there's still readme files at the top level that have been out of date for over a decade, but that's a bit beside the point. Tools march on, and we need to regularly update the corner of it we need. IMO that's to a large degree orthogonal to the SCM we're using for such a small project. An anecdote: last year I finally lost an old RedHat 7.3 server I'd been running as a backup machine and for some legacy tools I just *had* to have that for some reason have been left behind by modern distros. I considered rebuilding the machine but certainly I could hack something? Heh. Well.. after some dependency hell with one package I managed to build it from source; for the other I failed miserably. However it turned out the older version (it was Tcl based) worked once I was willing to dive in & debug some Tcl bugs. Yay.. put off from switching away from my trusty old tools for a few more years. :) Don't get me wrong, I love working with git. In my professional work all our projects have been converted to git (no need to worry about a windows client there, fortunately). However I don't consider it a painless transition for cvs/svn users by a long shot. You will lose time & hair in the short term. And even assuming an acceptable windows client, whoever is advocating the git switchover better anticipate at least 6 months answering questions from the developers who are just getting started with git. There's *still* some areas where git is not that user friendly in my book (arcane error messages to start). And a more powerful tool sometimes means more powerful ways of messing up. So to summarize, if plplot were put under git, that would be just peachy for me. However I'm not about to advocate it. :) -- Maurice LeBrun |
From: Geoffrey F. <Geo...@at...> - 2009-03-25 04:55:17
|
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 |
From: Alan W. I. <ir...@be...> - 2009-03-25 08:59:08
|
On 2009-03-24 22:55-0600 Geoffrey Furnish wrote: > 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. 3) Viable Windows client. (You have previously agreed to this requirement, but it should be formally in the list so there is no uncertainty about it.) Those first three requirements are important. Also, there is an important fourth requirement: 4) A consensus should emerge that we actually should make the move to git. This is obviously not a democracy so it is not a matter of voting, but we do form a small community where we want to encourage each other. Thus, we obviously do not want to railroad anybody with this decision. So I think the best way to proceed here is by consensus. How I would define such consensus is at least a substantial fraction of the active developers are enthused by the idea, and the rest of the developers willing to go along, i.e., nobody adamantly opposed. I am frankly not enthused about the move because I am satisfied by svn for my particular needs, and it will require a fair amount of effort on my part to get up to speed with git. OTOH, I like learning new techniques on general principles, and you are obviously not as comfortable with svn as I am so I would be willing to go along with a change to git. Thus, you can count me in the second group of those willing to help form a consensus on this issue, and I suspect there are others here that feel similarly given that the first 3 criteria above are satisfied. However, I think we need more individuals in the first group, i.e., more of our most active developers who are enthused about the idea before we can claim there is a consensus for it. IOW, I would hate to see us disrupt the PLplot development with such a move if it turns out few of the active developers are enthused about it. I don't think there is much doubt that git is potentially a good alternative for us, and you are obviously working hard at getting PLplot developers educated about git and ultimately enthused about the move to git. Thus, I am pretty sure the required consensus will form given persistence on your part. My opinion, though, is you are starting from relatively small git expertise and enthusiasm for git amongst PLplot developers so it is going to be a fairly long haul. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <and...@us...> - 2009-03-25 11:11:37
|
On Wed, Mar 25, 2009 at 01:58:57AM -0700, Alan Irwin wrote: > On 2009-03-24 22:55-0600 Geoffrey Furnish wrote: > > > 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. > > 3) Viable Windows client. (You have previously agreed to this requirement, > but it should be formally in the list so there is no uncertainty about it.) > > Those first three requirements are important. Also, there is an important > fourth requirement: > > 4) A consensus should emerge that we actually should make the move to git. > > This is obviously not a democracy so it is not a matter of voting, but we do > form a small community where we want to encourage each other. Thus, we > obviously do not want to railroad anybody with this decision. So I think > the best way to proceed here is by consensus. How I would define such > consensus is at least a substantial fraction of the active developers are > enthused by the idea, and the rest of the developers willing to go along, > i.e., nobody adamantly opposed. > > I am frankly not enthused about the move because I am satisfied by svn for > my particular needs, and it will require a fair amount of effort on my part > to get up to speed with git. OTOH, I like learning new techniques on general > principles, and you are obviously not as comfortable with svn as I am so I > would be willing to go along with a change to git. Thus, you can count me > in the second group of those willing to help form a consensus on this issue, > and I suspect there are others here that feel similarly given that the first > 3 criteria above are satisfied. > > However, I think we need more individuals in the first group, i.e., more of > our most active developers who are enthused about the idea before we can > claim there is a consensus for it. IOW, I would hate to see us disrupt the > PLplot development with such a move if it turns out few of the active > developers are enthused about it. > > I don't think there is much doubt that git is potentially a good alternative > for us, and you are obviously working hard at getting PLplot developers > educated about git and ultimately enthused about the move to git. Thus, I > am pretty sure the required consensus will form given persistence on your > part. My opinion, though, is you are starting from relatively small git > expertise and enthusiasm for git amongst PLplot developers so it is going to > be a fairly long haul. I am afraid I have recently been distracted elsewhere and I am one of the core developers not to have responded yet. My feelings mirror Alan's closely. We have only relatively recently gone through a big move to svn. This seems to be settling down with our developer and user base now and I'm a little unwilling to move without a clear benefit. It seems to me that we are a relatively small project, with few active developers at any one time. I'm not sure we really make use of the current facilities available in svn, and I suspect that a move to git won't radically change that for most developers. I think the reason we don't make much use of things like branching is as much to do with the fact we don't see the real need to, rather than the technical issues associated with doing so in svn. Having said all that, I am interested to read the discussion on git and I do now feel I appreciate better some of the potential advantages (and disadvantages) of git. I wouldn't say never to plplot using, I would just like to see rather more of a need for git and for a concensus to move. Any potential move would have to satisfy the 4 requirements above. I think your proposal for establishing a non-sourceforge git repository which links to svn is a sensible policy for now. It allows people to test it out and see if it works for them without committing to a wholesale move for the whole project. Any future move can then be made based on a rather more informed basis. Please keep the list posted on this. Thanks Andrew |
From: Geoffrey F. <Geo...@at...> - 2009-03-25 14:20:04
|
Alan W. Irwin writes: > On 2009-03-24 22:55-0600 Geoffrey Furnish wrote: > > > 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. > > 3) Viable Windows client. (You have previously agreed to this requirement, > but it should be formally in the list so there is no uncertainty about it.) Yes, of course. Sorry I dropped it in last night's e-mail. I realized the omission as I was drifting off to sleep. And providing a concrete way for windows developers to evaluate the windows git clients is a key part of why I want to establish a publicly visible git repo that I can push some stuff into, and others can clone/pull. > 4) A consensus should emerge that we actually should make the move to git. Yes, definitely agreed. That's why I'm discussing first, and inviting input. I do not want to alienate any of our core team with this. But I am really nonplussed with svn, much more so after having worked with both git and svn for a while now than I was at first. So I am quite willing to play the role of advocate here, despite Maurice's duly noted comments. Also, I think it is worth noting. When my corporate projects switched to git, the developer community was already pretty onboard with the realization that the old system was becoming an impediment. So the focus was on picking a successor system, and we did not really even consider a transition period. We just focused on how to do an initial import, and a one-time instantaneous cutover. For this project, we clearly have people who believe they're happy with svn, in addition to some who are not happy with svn. So a more gradual approach to the possibility of a switchover is clearly in order. Consequently, I'll focus some of my early efforts on facilitating people's use of the git-svn gateway system. I don't really like git-svn itself. As I mentioned in the first introductory note, a git-svn gateway to an svn repo is not nearly as appealing as a wholly-git infrastructure. But it's a way to get started, and people can use git behind a git-svn gateway. So this approach should let us get started with git, on an as-interested basis. And at least people will have the try-before-you-buy advantage. > This is obviously not a democracy so it is not a matter of voting, but we do > form a small community where we want to encourage each other. Thus, we > obviously do not want to railroad anybody with this decision. So I think > the best way to proceed here is by consensus. How I would define such > consensus is at least a substantial fraction of the active developers are > enthused by the idea, and the rest of the developers willing to go along, > i.e., nobody adamantly opposed. Agreed. > However, I think we need more individuals in the first group, i.e., more of > our most active developers who are enthused about the idea before we can > claim there is a consensus for it. IOW, I would hate to see us disrupt the > PLplot development with such a move if it turns out few of the active > developers are enthused about it. Also agreed. Andrew Ross writes: > I am afraid I have recently been distracted elsewhere and I am one of > the core developers not to have responded yet. My feelings mirror Alan's > closely. We have only relatively recently gone through a big move to > svn. This seems to be settling down with our developer and user base now > and I'm a little unwilling to move without a clear benefit. It seems to > me that we are a relatively small project, with few active developers at > any one time. I'm not sure we really make use of the current facilities > available in svn, and I suspect that a move to git won't radically > change that for most developers. I think the reason we don't make much > use of things like branching is as much to do with the fact we don't > see the real need to, rather than the technical issues associated with > doing so in svn. :-). Well, we'll see. I was happy to see Hazen start an svn branch the other day. I will be interested to see how that goes. My own experience with svn branching has led me to conclude that its much more broken than branches were in cvs. I have found many others voicing the same conclusion in blogs and articles around the internet. Stated charitably, I think svn branching works best if the branch gets merged before trunk moves too far. But the farther they drift (turnk and your branch), the mare laborious the merge becomes. This is one of the key things that I think is superiour about git. The "effort to merge" (any branch to any other branch, including master, or vice-versa) is just not something that git developers fret about. > Having said all that, I am interested to read the discussion on git and > I do now feel I appreciate better some of the potential advantages (and > disadvantages) of git. I wouldn't say never to plplot using, I would > just like to see rather more of a need for git and for a concensus to > move. > > Any potential move would have to satisfy the 4 requirements above. > > I think your proposal for establishing a non-sourceforge git repository > which links to svn is a sensible policy for now. It allows people to > test it out and see if it works for them without committing to a > wholesale move for the whole project. Any future move can then be made > based on a rather more informed basis. Exactly. > Please keep the list posted on this. Will do. And thanks to all who have contributed to this thread, both publicly and privately. -- Geoff |
From: Hazen B. <hba...@ma...> - 2009-03-26 18:26:58
|
Geoffrey Furnish wrote: > > :-). Well, we'll see. I was happy to see Hazen start an svn branch the > other day. I will be interested to see how that goes. Well I wasn't actually planning on taking it very far, so I don't anticipate too much trouble :). I'll take this opportunity to formalize my vote of ambivalence on the move to git. If we decide to move that is ok with me, if we don't that is also okay. I'm not enough of an expert on version control to have much of an opinion, beyond that we should probably try to avoid changing systems to frequently. -Hazen |
From: Arjen M. <arj...@de...> - 2009-03-27 07:33:51
|
On 2009-03-26 19:26, Hazen Babcock wrote: > I'll take this opportunity to formalize my vote of ambivalence on the > move to git. If we decide to move that is ok with me, if we don't that > is also okay. I'm not enough of an expert on version control to have > much of an opinion, beyond that we should probably try to avoid changing > systems to frequently. Those are my sentiments as well. In general I am happy with SVN, but that may be mostly because I use it in a very straightforward manner :). (I have heard good stories about git, but I have no experience with it myself. I can not compare it to SVN or CVS) Regards, Arjen Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Werner S. <sm...@ia...> - 2009-03-26 12:54:08
|
Hi Geoffrey, > 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 can also provide a git repo, since I have a dreamhost account with plenty of space and transfer rate. The plplot wiki is already running there and I don't mind if the git repo is also there. Git on dreamhost should be possible: http://wiki.dreamhost.com/Git . AFAIU git it would also be no problem, if I cancel the account, since it's decentralized anyways and then you just would open another git repo somewhere else. At least we would have more control over the git repo this way. The servers are also located in the US. > > 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. It would be also cool if you document that on the wiki as well - http://www.miscdebris.net/plplot_wiki . So potential users know about the git repo before they download anything. > > > Comments welcome. As Andrew and Alan I'm also not to enthusiastic about that, since svn suits my needs, but I commit that I'm no expert on cvs/svn/git at all. But I could live with a move to git if it turns out, that it has advantages (or at least no disadvantages) and if enough core developers are in favour of such a move. But as already pointed out Windows support is a big issue for me. I would like to stick to Linux or Mac OS X for developing, but this is not the case and apart from that I also think that it is important to not turn the back on 90% of all developers/users. So Windows support is IMHO essential for projects like plplot if we like it or not. Regards, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2009-03-26 19:10:36
|
On 2009-03-26 13:53+0100 Werner Smekal wrote: > [...]Windows support is a big issue for me. I would like to stick to Linux > or Mac OS X for developing, but this is not the case and apart from > that I also think that it is important to not turn the back on 90% of > all developers/users. So Windows support is IMHO essential for > projects like plplot if we like it or not. Hi Werner: This is an interesting topic in its own right so I have given it a new subject line. I agree with you about the importance of PLplot on Windows. Although I don't have access to Windows myself and never expect to try PLplot on that platform except possibly under Wine, there is no doubt there is a huge number of knowledgeable Windows developers who could potentially build PLplot for themselves. The key evidence that compelled me to this conclusion long ago was the SF statistics on MinGW downloads which are typically (http://sourceforge.net/project/stats/?group_id=2435&ugn=mingw) 15000 to 20000 per day(!) However, the prospect of a huge potential market for Plplot is only part of why I think PLplot on Windows is important. There are positive network effects when groups of developers get together to work on a common project for multiple platforms. For example, our visibility support is used on all platforms and has received contributions from developers from all our platforms and similarly for our CMake-based build system. Given the huge potential market for PLplot on the windows side of things, I am a bit disappointed in the relatively few Windows users who appear to be taking advantage of PLplot (as roughly measured by the relatively small number of questions we get on plplot-general from those using PLplot on Windows platforms). I don't think that is our fault. Instead, because of all the PLplot driver dependencies, I think a more fundamental problem affecting PLplot on Windows is getting access to a consistently packaged set of free libraries. Obviously Cygwin attempts to respond to this need, but that is just one Windows distribution, and it cannot possibly satisfy everyone's needs/desires for consistently packaged free software on Windows. Contrast that with the Linux case where there are something like 500 different distributions all in healthy competition with each other to provide the best software packaging experience for users. Fortunately, CMake makes porting of free software to Windows platforms fairly straightforward. In fact, a project (see http://code.google.com/p/cmakeports/wiki/CMakePortsPlan) has recently been started to provide CMake-based build systems for those free software packages that have not yet created those on their own. One of the spin offs I hope to see from this project in the near future is one or more additional Windows distributions of free software based on MinGW and CMake that will give Cygwin some much-needed competition and also indirectly give PLplot a boost on Windows. Of course, the availability of the pango/cairo stack of libraries for Windows at http://www.gtk.org/download-windows.html for the 7(!) cairo devices and the Qt4 stack of libraries for Windows at http://www.qtsoftware.com/downloads for the 9(!) qt devices also gives a tremendous boost to PLplot on Windows. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |