While I don't wish to sound trite, I do think almost everyone here knows what everyone else is going to say, and maybe trying to headstart the discussion is a bad move, and presumptuous, but allow me to throw out an idea.
I think we are more or less in agreement that: 1) git would lower the barrier of entry for new developers, 2) git offers some significant benefits when it comes to sharing and tracking patches, specifically in the realm of testing and/or release branching. 3) git-svn is an acceptable and stable program, while we should not base a system off of it, asking that developers do use it is not out of the question. 4) A complete migration at this point is foolhardy, we just did a big one, the sysadmin team is strained, and simply put, Subversion isn't all that bad. 5) Asking that translators and documenters learn a new (and radially different) version control system is unreasonable. While the concepts behind git may work and make great sense for a Computer Science major, we would probably lose not only a lot of productive translator time (which is unbelievably valuable as it is), but we might even lose translators to the frustration of an overly complicated system. 6) 3rd party tools and build systems (including our own, like jhbuild) will suffer from a change, and even moreso from a half-assed one. This swings both ways, we don't want to implement a change to please some that leaves the Gnome code hopelessly divided, but at the same time, we don't want to end up with new projects that are close to gnome, or indeed even officially part of it, moving their development away from Gnome. That being said, I see the following as a bordering-on-sanity approach to use as a starting point for a realistic debate over weather Gnome should go distributed or not. My proposal is centered around Gnome maintaining its centralized development style, while capitalizing on the availability of tools that make collaboration in such an environment much easier. 1) We establish a 'central' git repository, providing remote access via the native git client, and webdav or ftp (a firewall friendly protocol) and if the server can handle the load, rsync. Well call this setup git.gnome.org. It is important to note, that upon git.gnome.org's conception, there has been no formal migration of anything. This is simply a central place for the sharing of git repositories and branches. 2) Even with the addition of git.gnome.org, at this point, Subversion remains the final and master copy of all Gnome source. Individual projects are free to branch and merge and frolic as they please, but it is imperative that the Subversion trunk remain the tip of active development. Be that through the forwarding of patches through git systems, or as it always has taken place. However, new projects are asked to use git, and simply treat Subversion as the master branch, where all changes are eventually pushed at release time. 3) At this point, if all has gone well, we allow evangelist project maintainers to move to git exclusively if they so desire, this will help us asses the migration tools and times for a realistic assessment of the next step. 4) The final step would be the introduction of git clones of every Subversion module. Luckily, if done over a fast LAN (or ideally, harddisk) this can be done very quickly, even for long-history'ed projects. In addition, these git clones would be updated at some regular interval (say hourly... really depends on the realistic cost of the operation, and how active SVN still is) At this point we have something not dissimilar from launchpad's vcs-imports component. In short, projects are free to work in either system, the goal would be (in my mind) that most development happened in git, revolving around its distributed and free flowing development model. However, since with git all the changes going upstream can just be merged into the maintainers branch, and (s)he can push those changes to subversion, so we still have all our source history in one format and one place, should we choose to not stick with git. Known Issues: * Potentially long 'split-code' period - Agreed, this could happen, but the reason that we still require that subversion trunk represent an accurate snapshot of development is so that the code can always be found, and we have the full revision history, we are just embracing the advantages of a distributed system, and encouraging the Gnome community to embrace recent advances in technology. **Fact Alert** This is not at all dissimilar from what Mozilla has started doing with mercurial and CVS, by all reports, its working quite well, and developers that where panicked over the complete move to hg[1], have learned the tool, and are comfortable with it, if not excited (Revision control isn't really something one can ever get to happy about, its always 'in the way' to some extent) * Doesn't address the translators learning new software component. - Yes, it does, the beauty of forcing the SVN repos to stay active, while using them with git is that as long as the git->svn action only involves one git branch and one subversion branch, things are neat and cheery. Now using git to manage branches in subversion is just plain stupid, but translators could continue to work in the old system as long as the developers remember to occasionally fetch any changes. This reflects a serious change in mentality that DRCS' can enable. Merging is not the devil, its cheap, easy, reliable, clean, and part of distributed development. * It's half-assed and doesn't accomplish anything that people couldn't do on their own with some webspace, or even just a half decent upstream connection. - I believe that without some unifying place/effort, no module or development team as a whole will actually take advantage of a distributed system while still maintaining their gnome SVN repo. By offering something relatively simple (and low-cost) service, we could offer something that is not only of great interest to the community, but the productivity enhancements etc. that come from allowing free-form branching etc as provided by git. A discussion of the actual merits of Git vs. SVN in an abstract won't get us anywhere, we have to evaluate Gnome's need (is there one? or is it a want?). I fully expect (and look forward to) the no doubt heated discussion that will probably evolve in this thread. However, in the spirit of actually getting something done, please focus on what _Gnome_ needs or what you as a _Gnome Developer_ need, not just what you think would be cool and fun to play with for a while (no doubt that git has plenty of that appeal). Holy Crud, thats a long e-mail. My apologies, I seem to have rambled myself a bit /me *blushes* I'll try to keep a healthy record of valid proposals/arguments/concerns etc at: http://live.gnome.org/gitMigration (that includes links to mail threads when they are up) Cheers, Kevin Kubasik [1](I believe that all upstream work after FF 3.0 and Gecko 1.9 will be in hg, but correct me if I'm wrong) On 9/7/07, Zeeshan Ali <[EMAIL PROTECTED]> wrote: > Hi! > > On 9/7/07, Olav Vitters <[EMAIL PROTECTED]> wrote: > > On Fri, Sep 07, 2007 at 11:57:19AM +0300, Zeeshan Ali wrote: > > > About the svn access, all centralized VCS's are meant for > > > dictatorships. If the gnome foundation really wants to improve the > > > situation, i recommend moving to git or some other non-distributed VCS > > > instead of brain-dead centralized svn for the following reason: > > > > This will take 12x longer than fixing the problem. We'll end up with a > > workaround (as someone still finally has to commit). > > How come? The developer with write-access to the main repo (who is > acting as the proxy) would get the commits pushed to his repo from the > other developer and he would just push them upstream along with his > commits. As me and Kalle tried to point out, with git you have a lot > of freedom to do things in many different ways, which isn't true about > SVN. > > > Finally, people can > > already use a D-SCM together with SVN (git/bzr/.. support SVN). So if > > D-SCM would solve things, there wouldn't be an issue currently. > > As I mentioned in one of my previous emails, the problem would have > been far too small to make a big fuss about it if either A. it was a > matter of a git repo instead of an SVN repo or B. the proxy developer > and the developer needing write access, had decided to use git > together with git-svn at their end. > > > > 1. Developers can clone the main repo and the maintainers (people with > > > write-access) can just pull from their cloned repos. This way a > > > developer won't really need write access and he'll just keep on > > > committing his changes to his repo and inform the maintainer(s) about > > > his newest cool changes and the maintainer(s) can pull those changes > > > if they like/need them. > > > > I call that a workaround. The problem is the access to the main repos. > > If the maintainer doesn't pull from every developer you end up with the > > same problem. At one point someone needs to do something (give access to > > something / pull). > > The developer doesn't necessarily need to 'pull'. What you are > addressing is just one of the many ways things can operate when Git is > being used. Please read above. I mentioned at least two different > modes of operation which are not mutually exclusive. > > > > 2. #1 is a generic advantage of using a non-distributed VCS but the > > > reason i would go for git is speed: it's amazingly super fast in all > > > it's operations and will save a lot of precious developer time. > > > > You are ignoring the drawbacks and that it won't solve this issue. > > For example? > > > I am all for D-SCM, but it is not a hammer. > > That might be but they are much better than centralized SCMs, at > least git is quite obviously superior to SVN. > > > > 3. No need to maintain two levels of changelog. > > > > That is not true. The ChangeLog requirement has been discussed before. > > Suggest to read the archives for that discussion (here / d-d-l). > > I searched the archive and topics of the mails i found, didn't seem > relevant so it would be nice if you either provide me a link to the > thread or summarize the conclusion. We are using SVN so ChangeLog > requirement obviously makes sense but I can't imagine it making any > sense at all in D-SCMs especially git since i can always get the > changelog using `git log`. > > > > For details on why a good and > > > self-respecting developer wouldn't ever consider using svn over git, > > > you have to watch this presentation by Linus: > > > http://video.google.com/videoplay?docid=-2199332044603874737 . > > > > Last time I watched this it only talked about the benefits of a > > distributed SCM vs non-distributed SCM. Further, the style of presenting > > is very flame-ish. It only serves as advocacy to perhaps try some other > > D-SCM. > > You need to look at it a bit objectively. Linus says "you are stupid > and ugly" because you truly are stupid if you prefer to use SVN or any > centralized SCM and he clearly points out most of the reason why this > it the honest truth. > > > Btw, generalising my arguments against git to 'sucky UI' is > > a misrepresentation. > > I won't commit that mistake but i didn't really see any other > convincing argument either. :) > > -- > Regards, > > Zeeshan Ali > FSF member#5124 > _______________________________________________ > foundation-list mailing list > foundation-list@gnome.org > http://mail.gnome.org/mailman/listinfo/foundation-list > -- Cheers, Kevin Kubasik http://kubasik.net/blog _______________________________________________ foundation-list mailing list foundation-list@gnome.org http://mail.gnome.org/mailman/listinfo/foundation-list