Just to give some visibility into some of the work bubbling away these days:
Cairo renderer: Bulia has taken point on investigation of conversion to Cairo. Some tough problems have been uncovered but we're gaining a clearer picture of what needs done. Presently this looks like it will require an all at once brute force approach, rather than incremental refactoring. If so, we'll need to reach a decision on how to undertake that while minimizing disruption to SVN HEAD users.
Build system: There is definitely a concensus that our current build system sucks. Options include CMAKE, Bob's buildtool, or just a cleaned up automake. We really need to have interested parties mind meld and find a single solution.
Version control system: Mental has been experimenting with git and trying to get it to operate with svn. This study is still very early on, but if it works out well, one day we may begin encouraging developers to use git.
Bug tracking: I have been experimenting with use of Mantis with the goal of replacing our SF bug tracker. It looks good, but the principle issue is how to migrate the bugs and their history from SF to Mantis. I'm also interested in seeing if it can be combined well with Drupal, maybe along with Pootle. Any drupalheads out there?
Manual: We've got a good unofficial non-free manual/book and several [semi-]official incomplete free manuals. There is discussion about if efforts can be combined to produce a good official free manual.
Anyway, I've probably missed something, but I think that covers the pending changes that are percolating. Most of these would benefit from discussion, so we can make sure there is a rough concensus favoring the change - so if you have concerns about any of these changes, now's a good chance to bring 'em up.
Bryce
On Tue, 2007-02-27 at 13:51 -0800, Bryce Harrington wrote:
Just to give some visibility into some of the work bubbling away these days:
Cairo renderer: Bulia has taken point on investigation of conversion to Cairo. Some tough problems have been uncovered but we're gaining a clearer picture of what needs done. Presently this looks like it will require an all at once brute force approach, rather than incremental refactoring. If so, we'll need to reach a decision on how to undertake that while minimizing disruption to SVN HEAD users.
Yes, I've got a shovel? Where's the plan?
Build system: There is definitely a concensus that our current build system sucks. Options include CMAKE, Bob's buildtool, or just a cleaned up automake. We really need to have interested parties mind meld and find a single solution.
CMake seems good, but I guess its the best one wins and/or who puts in the most time ;)
Version control system: Mental has been experimenting with git and trying to get it to operate with svn. This study is still very early on, but if it works out well, one day we may begin encouraging developers to use git.
Yes, hybrid approach good. But if it ain't broke, why break it ;)
Bug tracking: I have been experimenting with use of Mantis with the goal of replacing our SF bug tracker. It looks good, but the principle issue is how to migrate the bugs and their history from SF to Mantis. I'm also interested in seeing if it can be combined well with Drupal, maybe along with Pootle. Any drupalheads out there?
Lets discuss this somemore. I've been hacking on pootle for Creative Commons so that we can get near live translations of our code projects using pootle's web interface (http://translate.creativecommons.org/)
I abhor drupal, and wonder what the endgame is? Is that for our site? I'm all for just going 100% wordpress since its so easily extensible...yes, I know...we tried the hybrid approach before ;)
Oh, it would be great to have a generalized issue tracker rather than just a "bug tracker," since we want to track more than just bugs, right? We need patch, features, bugs at minimum...
Manual: We've got a good unofficial non-free manual/book and several [semi-]official incomplete free manuals. There is discussion about if efforts can be combined to produce a good official free manual.
Yes, this would be great to standardsize behind something like how scribus does it: http://docs.inkscape.org and/or http://manual.inkscape.org We need an official place for this IMO. This should be easy to do. I think we should just make this a solid portal into the various efforts and let the best rise to the top...
Anyway, I've probably missed something, but I think that covers the pending changes that are percolating. Most of these would benefit from discussion, so we can make sure there is a rough concensus favoring the change - so if you have concerns about any of these changes, now's a good chance to bring 'em up.
Bryce
Thanks Bryce!!!
Jon
[Limiting followup for this thread to inkscape-devel@]
On Tue, Feb 27, 2007 at 02:02:47PM -0800, Jon Phillips wrote:
On Tue, 2007-02-27 at 13:51 -0800, Bryce Harrington wrote:
Just to give some visibility into some of the work bubbling away these days:
Cairo renderer: Bulia has taken point on investigation of conversion to Cairo. Some tough problems have been uncovered but we're gaining a clearer picture of what needs done. Presently this looks like it will require an all at once brute force approach, rather than incremental refactoring. If so, we'll need to reach a decision on how to undertake that while minimizing disruption to SVN HEAD users.
Yes, I've got a shovel? Where's the plan?
It's probably going to involve adding conditionalized #defines for Cairo alternate calls in key places, but I don't think a specific plan has been decided on yet.
Build system: There is definitely a concensus that our current build system sucks. Options include CMAKE, Bob's buildtool, or just a cleaned up automake. We really need to have interested parties mind meld and find a single solution.
CMake seems good, but I guess its the best one wins and/or who puts in the most time ;)
No, I think in this case we really do need to have the people who care about this a lot to talk it through and come to a unified concensus in what to do. Maybe we need to hold an IRC meeting or something?
Version control system: Mental has been experimenting with git and trying to get it to operate with svn. This study is still very early on, but if it works out well, one day we may begin encouraging developers to use git.
Yes, hybrid approach good. But if it ain't broke, why break it ;)
I think it's a "best tool for the job" type of issue here. git uses a different model than CVS/SVN that is better at certain kinds of tasks. Also, cairo uses git, so there could be some advantages in that. But at this time it's just to experiment and see what can be done.
Bug tracking: I have been experimenting with use of Mantis with the goal of replacing our SF bug tracker. It looks good, but the principle issue is how to migrate the bugs and their history from SF to Mantis. I'm also interested in seeing if it can be combined well with Drupal, maybe along with Pootle. Any drupalheads out there?
Lets discuss this somemore. I've been hacking on pootle for Creative Commons so that we can get near live translations of our code projects using pootle's web interface (http://translate.creativecommons.org/)
Oh, it would be great to have a generalized issue tracker rather than just a "bug tracker," since we want to track more than just bugs, right? We need patch, features, bugs at minimum...
Right, I guess I figure this goes without saying. However I'm thinking that making these categories isn't the right way to go. Instead, it should have a way to search for "issues that have patches attached to them", or to distinguish between issues that result in data loss, or crashes, or usability concerns, or etc.
The more ways we can mine the bugs, I think the more useful it'll be. Presently, once something gets filed as an RFE, or prioritized to 6 or lower, it tends to not get much attention, especially if it isn't assigned to anyone. The more categorization, keywording, relating, etc. etc. we can do, the better.
Manual: We've got a good unofficial non-free manual/book and several [semi-]official incomplete free manuals. There is discussion about if efforts can be combined to produce a good official free manual.
Yes, this would be great to standardsize behind something like how scribus does it: http://docs.inkscape.org and/or http://manual.inkscape.org We need an official place for this IMO. This should be easy to do. I think we should just make this a solid portal into the various efforts and let the best rise to the top...
Yes, I think the effort is mostly just touching base with all the people working on various manual/tutorial things and organizing an agreed on strategy for integrating all the efforts in a way that gains them each the credit they deserve, but results in a single official product.
Bryce
Daniel Culver danielculver@...107...
On Feb 27, 2007, at 1:51 PM, Bryce Harrington wrote:
Build system: There is definitely a concensus that our current build system sucks. Options include CMAKE, Bob's buildtool, or just a cleaned up automake. We really need to have interested parties mind meld and find a single solution.
Bryce could you expand on the build options if you have the time? Thanks
On Tue, Feb 27, 2007 at 07:12:05PM -0800, Daniel Culver wrote:
On Feb 27, 2007, at 1:51 PM, Bryce Harrington wrote:
Build system: There is definitely a concensus that our current build system sucks. Options include CMAKE, Bob's buildtool, or just a cleaned up automake. We really need to have interested parties mind meld and find a single solution.
Bryce could you expand on the build options if you have the time? Thanks
Aaron Spike posted a better summarization of build options than I could achieve a week or two ago; I'd recommend going through the gmane.org archives for inkscape-devel and fishing that thread out.
Bryce
2007/2/27, Bryce Harrington <bryce@...983...>: //// cut ////
Bug tracking: I have been experimenting with use of Mantis with the goal of replacing our SF bug tracker. It looks good, but the principle issue is how to migrate the bugs and their history from SF to Mantis. I'm also interested in seeing if it can be combined well with Drupal, maybe along with Pootle. Any drupalheads out there?
//// cut ////
Bryce
I looked at the version demonstration of the Mantis[1] and I did not find simple and easy as the Trac[2]. To use the Trac it does not demand much experience.
I don't find correct to use drupal and to join with other tools, we can use the proper Trac system.
Pootle is a very cool tool, I did not have problems to use in the Ink-BR, but I find that the tests had not been enough made by me. I suggest to create "Pootle-test", if did not have errors presented during the execution during one release, takes off it of the period of tests.
[1] http://www.futureware.biz/mantisdemo [2] http://trac.edgewall.org/
.ValessioBrito ://valessio.ul-jb.org/ PS: Translator pt_BR to en_US in http://br.babelfish.yahoo.com/
Comparison Mantis and Trac, others...
http://en.wikipedia.org/wiki/Comparison_of_ticket-tracking_systems
.ValessioBrito
2007/2/28, ValessioBrito <valessio@...155...>:
2007/2/27, Bryce Harrington <bryce@...983...>: //// cut ////
Bug tracking: I have been experimenting with use of Mantis with the goal of replacing our SF bug tracker. It looks good, but the principle issue is how to migrate the bugs and their history from SF to Mantis. I'm also interested in seeing if it can be combined well with Drupal, maybe along with Pootle. Any drupalheads out there?
//// cut ////
Bryce
I looked at the version demonstration of the Mantis[1] and I did not find simple and easy as the Trac[2]. To use the Trac it does not demand much experience.
I don't find correct to use drupal and to join with other tools, we can use the proper Trac system.
Pootle is a very cool tool, I did not have problems to use in the Ink-BR, but I find that the tests had not been enough made by me. I suggest to create "Pootle-test", if did not have errors presented during the execution during one release, takes off it of the period of tests.
[1] http://www.futureware.biz/mantisdemo [2] http://trac.edgewall.org/
.ValessioBrito ://valessio.ul-jb.org/ PS: Translator pt_BR to en_US in http://br.babelfish.yahoo.com/
On Tuesday 27 February 2007 16:51, Bryce Harrington wrote:
Just to give some visibility into some of the work bubbling away these days:
Cairo renderer: Bulia has taken point on investigation of conversion to Cairo. Some tough problems have been uncovered but we're gaining a clearer picture of what needs done. Presently this looks like it will require an all at once brute force approach, rather than incremental refactoring. If so, we'll need to reach a decision on how to undertake that while minimizing disruption to SVN HEAD users.
Build system: There is definitely a concensus that our current build system sucks. Options include CMAKE, Bob's buildtool, or just a cleaned up automake. We really need to have interested parties mind meld and find a single solution.
The only problem with the current build system is that too many items are not included either in the build file itself or the libs of many systems. For example there is the special garbage collector software. If that is always required, but seldom found, then it should be integrated in the build file. Similarly all the special libraries needed from the Gnome distro should be included for those of us that don't have Gnome installed.
I use Slackware 11 version of Linux. It took me a long time to find the Dropline distro, which finally adds all those pesky libraries that Inkscape needs and current Slackware doesn't have.
John Culleton Able Indexing and Typesetting Precision typesetting (tm) at reasonable cost. Satisfaction guaranteed. http://wexfordpress.com
Just to give some visibility into some of the work bubbling away these days:
Build system: There is definitely a concensus that our current build system sucks. Options include CMAKE, Bob's buildtool, or just a cleaned up automake. We really need to have interested parties mind meld and find a single solution.
CMAKE is ok. It is well supported and can generate pseudo-native projects for a number of compilers in addition to plain makefiles. But I do find it kind of a pain in the butt to use and a little bit confusing.
I don't think a cleaned up automake will help Windows users much. But I could be wrong. The only way I know to build on Windows is using buildtool. Maybe cleaned up automake could make things working with MSYS/Cygwin? It would be nice to be able to use other compilers, but on the other hand mandating GCC eliminates a lot of headaches.
I'm not sure why buildtool was really necessary in the first place given the number of build systems already out there. But of the ones I'm familiar with, buildtool looks to be most similar to "Bakefiles" (http://www.bakefile.org/) used and created by the wxWidgets folks. At least they're similar in the sense that both chose to use xml for some (IMHO misguided) reason. Build descriptions are not tree-structured data so XML doesn't really make so much sense to me. Lisp or scheme (guile?) make more sense if you want something that's easy to parse and is capable of describing both data and execution flow succinctly.
There's also SCONS, but it doesn't come with a lot of built-in logic for building cross-platform apps. It's more like a 'make' replacement on steroids than an autotools replacement. But python already seems to be a big part of Inkscape so maybe it makes sense to go with SCONS. Blender has a SCONS building system now.
Version control system: Mental has been experimenting with git and trying to get it to operate with svn. This study is still very early on, but if it works out well, one day we may begin encouraging developers to use git.
Have you looked at Monotone?
My problem with git is that the community seems very uninterested in providing a cross-platform tool. The attitude seems to be: git is for working on the Linux kernel and if you're not working on the Linux kernel or not working on Linux, then good luck. The best answer I could get when looking into git for accessing the Cairo sources was that "I should be able to get git to compile under cygwin." I can't remember if I tried or not. I think I tried and it didn't work for some reason so I gave up because I really only needed a snapshot of the Cairo src.
On the other hand Monotone seems to be much more cross-platform friendly, with clients _prebuilt_ for various platforms and linked to right from the project's front page. A little digging also turns up various GUI clients, too.
(To be honest, I actually only know about Monotone because it's what the Gaim -- now Pidgin -- folks just announced they're switching to, but that's endorsement enough for me.)
Looking now, I see git is available precompiled from Cygwin at last, but I still get an uneasy feeling about relying on a tool that is so unapologetically Linux-centric as the backbone for a cross-platform app like Inkscape. Platform-specific issues like line-end translation do exist, and I would be surprised if Git devs proved to be very receptive about dealing with such issues since they can't even be bothered to make link for a Mac or Windows client on their web Page. Monontone, on the other hand has links for Win, Mac, rpm and a slew of deb formats right there on page 1.
--bb
Bill Baxter wrote:
Looking now, I see git is available precompiled from Cygwin at last, but I still get an uneasy feeling about relying on a tool that is so unapologetically Linux-centric as the backbone for a cross-platform app like Inkscape. Platform-specific issues like line-end translation do exist, and I would be surprised if Git devs proved to be very receptive about dealing with such issues since they can't even be bothered to make link for a Mac or Windows client on their web Page.
I spent some time in #git a few weeks back talking about win32 support with the devs. I must say they were nothing but helpful. At that time there wasn't a fully polished win32 git client, but they helped me work through compiling a native git with mingw. I'm sure they would have also helped me work through installing git with cygwin, but I only spent a few days there. We also discussed git on win32 on this mailing list at about the same time (you could check the archives to catch up on all the details). My experience with win32 and the git community runs contrary to your supposition. No there isn't a finly polished git client for us to use today, but this is nothing but a manpower problem.
Aaron Spike
On 4/10/07, Aaron Spike <aaron@...476...> wrote:
Bill Baxter wrote:
Looking now, I see git is available precompiled from Cygwin at last, but I still get an uneasy feeling about relying on a tool that is so unapologetically Linux-centric as the backbone for a cross-platform app like Inkscape. Platform-specific issues like line-end translation do exist, and I would be surprised if Git devs proved to be very receptive about dealing with such issues since they can't even be bothered to make link for a Mac or Windows client on their web Page.
I spent some time in #git a few weeks back talking about win32 support with the devs. I must say they were nothing but helpful. At that time there wasn't a fully polished win32 git client, but they helped me work through compiling a native git with mingw. I'm sure they would have also helped me work through installing git with cygwin, but I only spent a few days there. We also discussed git on win32 on this mailing list at about the same time (you could check the archives to catch up on all the details). My experience with win32 and the git community runs contrary to your supposition.
That's good to hear. Times do change. It was about a year ago when I last looked into Git.
No there isn't a finly polished git client for us to use today, but this is nothing but a manpower problem.
Well, manpower is really everything when it comes to an open source project isn't it? The fact that Git still doesn't have enough of it to get binary releases up on the web page for 2 of the 3 most popular OS's just seemed like a red flag to me, that's all.
I do see they suggest a 1-click windows installer as a SoC project, though. So they're thinking about it. And the fact that they are part of SoC to begin with says good things, too.
And I'm definitely relieved to find that at least Cygwin has precompiled Git now.
--bb
On Monday 09 April 2007 22:56, Bill Baxter wrote:
On 4/10/07, Aaron Spike <aaron@...476...> wrote:
Bill Baxter wrote:
Looking now, I see git is available precompiled from Cygwin at last, but I still get an uneasy feeling about relying on a tool that is so unapologetically Linux-centric as the backbone for a cross-platform app like Inkscape. Platform-specific issues like line-end translation do exist, and I would be surprised if Git devs proved to be very receptive about dealing with such issues since they can't even be bothered to make link for a Mac or Windows client on their web Page.
As a Linux user I vote for traditional ./configure, make and make install just like most other Linux apps use. I have no opinion on how the program should be packaged for Windows users.
I generally stick to released versions rather than overnight development products. But if I were tempted in that direction, again the traditional cvs system is familar to most and would be the least troublesome method of presentation.
Variations from the normal as described above cause me nothing but grief. Early in my computing career I was urged to "Keep it simple, stupid (KISS)." I pass this plea on to the developers. Burdening the end user with downloading/compiling/learning the latest bleeding edge installation package is a major hindrance and can discourage use unnecessarily.
Just my 2c.
John R. Culleton wrote:
On Monday 09 April 2007 22:56, Bill Baxter wrote: As a Linux user I vote for traditional ./configure, make and make install just like most other Linux apps use. I have no opinion on how the program should be packaged for Windows users.
A pro for both buildtool and CMake is that they will use the same process on Linux, Mac and Windows.
I generally stick to released versions rather than overnight development products. But if I were tempted in that direction, again the traditional cvs system is familar to most and would be the least troublesome method of presentation.
Too late for that. We switched to SVN quite some time ago. I think I can speak for the other developers when I say that we don't regret it. If git will be able to support the development practices that we need to use to do the heavy refactoring that still needs to be completed on the inkscape code base without much additional complexity on any supported platform, it will be a huge win and I don't foresee regret there either.
Variations from the normal as described above cause me nothing but grief. Early in my computing career I was urged to "Keep it simple, stupid (KISS)." I pass this plea on to the developers. Burdening the end user with downloading/compiling/learning the latest bleeding edge installation package is a major hindrance and can discourage use unnecessarily.
We cater simplicity to our end users by supplying a number of frequent snapshot binary packages. Simplicity for new developers is a very high priority for us. But we still have to weigh these priorities against the pain that the core developers feel on a daily basis. Git may have a slight learning curve, but with a tool such as cogito it is a very smooth transition from the SVN that we have grown to love. CMake replaces autogen.sh and configure and retains the normal make. autotools is a complicated system that requires significant experience to adminsiter. If anything CMake would be getting simpler!
Aaron Spike
On Tuesday 10 April 2007 10:39, Aaron Spike wrote:
John R. Culleton wrote:
On Monday 09 April 2007 22:56, Bill Baxter wrote: As a Linux user I vote for traditional ./configure, make and make install just like most other Linux apps use. I have no opinion on how the program should be packaged for Windows users.
A pro for both buildtool and CMake is that they will use the same process on Linux, Mac and Windows.
But they aren't used by Gimp, Scribus, TeX etc. all of which run on all three platforms. Linux users generally stick to Linux, Mac user to Mac and so on.
I generally stick to released versions rather than overnight development products. But if I were tempted in that direction, again the traditional cvs system is familar to most and would be the least troublesome method of presentation.
Too late for that. We switched to SVN quite some time ago. I think I can speak for the other developers when I say that we don't regret it. If git will be able to support the development practices that we need to use to do the heavy refactoring that still needs to be completed on the inkscape code base without much additional complexity on any supported platform, it will be a huge win and I don't foresee regret there either.
Variations from the normal as described above cause me nothing but grief. Early in my computing career I was urged to "Keep it simple, stupid (KISS)." I pass this plea on to the developers. Burdening the end user with downloading/compiling/learning the latest bleeding edge installation package is a major hindrance and can discourage use unnecessarily.
We cater simplicity to our end users by supplying a number of frequent snapshot binary packages. Simplicity for new developers is a very high priority for us. But we still have to weigh these priorities against the pain that the core developers feel on a daily basis. Git may have a slight learning curve, but with a tool such as cogito it is a very smooth transition from the SVN that we have grown to love. CMake replaces autogen.sh and configure and retains the normal make. autotools is a complicated system that requires significant experience to adminsiter. If anything CMake would be getting simpler!
I can live with SVN.
One last plea, offered earlier. If there is something magic about the Boehm garbage collector it should be included in the source release if legally possible. I know of no other application that requres it and Slackware at least does not offer it even as an option. Or perhaps it could be deleted altogether. The first thing the user discovers after downloading is that they have to download, compile and install yet another package. This is an instant turnoff.
John R. Culleton wrote:
One last plea, offered earlier. If there is something magic about the Boehm garbage collector it should be included in the source release if legally possible. I know of no other application that requres it and Slackware at least does not offer it even as an option. Or perhaps it could be deleted altogether. The first thing the user discovers after downloading is that they have to download, compile and install yet another package. This is an instant turnoff.
This is not meant to start a favorite distro flame war, but realize that you are asking Inkscape to change its dependencies based upon the user experience provided by your distro. Perhaps you could submit a request to slackware asking for Inkscape and its dependencies be packaged. This would certainly benefit inkscape more than an attempt to remove garbage collection from the codebase. Also I think that there are a number of negatives with including other packages in our source distribution.
There are a few other pacakges that require libgc. Here is the list from Ubuntu Dapper Drake:
aaron@...1932...:~$ apt-cache showpkg libgc1c2 Package: libgc1c2 Versions: 1:6.6-2ubuntu1(/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_dapper_main_binary-i386_Packages)(/var/lib/dpkg/status)
Reverse Depends: w3m-img,libgc1c2 w3m,libgc1c2 inkscape,libgc1c2 w3mmee,libgc1c2 w3m-img,libgc1c2 synopsis,libgc1c2 stalin,libgc1c2 openc++,libgc1c2 oo2c,libgc1c2 libocc0c2a,libgc1c2 goo,libgc1c2 chase,libgc1c2 asymptote,libgc1c2 w3m,libgc1c2 libgc-dev,libgc1c2 1:6.6-2ubuntu1 inkscape,libgc1c2
Aaron Spike
On 4/10/07, Aaron Spike <aaron@...476...> wrote:
John R. Culleton wrote:
On Monday 09 April 2007 22:56, Bill Baxter wrote: As a Linux user I vote for traditional ./configure, make and make install just like most other Linux apps use. I have no opinion on how the program should be packaged for Windows users.
A pro for both buildtool and CMake is that they will use the same process on Linux, Mac and Windows.
One of the advantages of Bakefile is that it does generate native build scripts. On Linux it spits out the regular autotools ./configure; make; make install scripts. On Windows it spits out real Visual Studio projects (or a variety of other makefiles/projects for other compilers).
The thing about CMake is that the Visual Studio projects it generates aren't quite normal. They look like regular Visual Studio projects but there are various oddities, like if you ran CMake's configure tool to generate a release build, the generated Visual Studio project is incapable of creating a Debug build (despite listing both Debug and Release targets in the configurations menu). You have to rerun the configure tool and create separate project files for the Debug build. It seems that the project files it generates, though superficially Visual Studio projects, somehow actually rely on CMAKE under the hood to implement all the build logic, rather than relying on the native tool (Visual Studio in this case).
Bakefile, on the other hand, generates real plain vanilla Visual Studio projects that have no other dependencies and which use no behind the scenes hanky-panky. And on Linux they generate regular autotools/Makefiles stuff.
I generally stick to released versions rather than overnight development products. But if I were tempted in that direction, again the traditional cvs system is familar to most and would be the least troublesome method of presentation.
Too late for that. We switched to SVN quite some time ago. I think I can speak for the other developers when I say that we don't regret it. If git will be able to support the development practices that we need to use to do the heavy refactoring that still needs to be completed on the inkscape code base without much additional complexity on any supported platform, it will be a huge win and I don't foresee regret there either.
I think the truly disconnected and distributed model used by git, monotone, mercurial, or darcs is the way to go for the future. From what I understand one key thing they all offer is the ability to seamlessly create branches *locally*, so anyone is free to create a variety of branches of their own and do experiments without needing any write permissions on the official repository. That plus the ability to make local commits even when you're offline at a coffee shop or on an airplane just sounds wonderful. So I'm all for the move.
I think Carl Worth did a pretty good job at selling Git when he moved Cairo over to git from CVS: http://lists.freedesktop.org/archives/cairo/2006-February/006255.html
--bb
participants (7)
-
Aaron Spike -
Bill Baxter -
Bryce Harrington -
Daniel Culver -
John R. Culleton -
Jon Phillips -
ValessioBrito