{"thread":{"id":"7901","subject":"\"Producting Open Source Software\" book and distributed SCMs","startedAt":"2007-04-29T23:20:42Z","lastAt":"2007-05-01T23:13:10Z","messageCount":9,"participants":["Jakub Narebski","Johannes Schindelin","Theodore Tso","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"40726","messageId":"200704300120.42576.jnareb@gmail.com","threadId":"7901","inReplyTo":null,"subject":"\"Producting Open Source Software\" book and distributed SCMs","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-04-29T23:20:42Z","receivedAt":"2007-04-29T23:20:42Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"I have read lately classic book \"Producing Open Source Software. How to \nRun a Successful Free Software Project\" by Karl Fogel (2005).\n\nAmong others, author advocates using version control system as a basis \nfor running a project. In \"Choosing a Version Contol System\" he writes:\n\n  As of this writing, the version control system of choice in the free\n  software world is the Concurrent Versions System or CVS.\n\nFurther on much of examples of managing project and managing volunteers \nrevolves around the idea of \"commit access\", and it is assumed \nimplicitely that version control system is centralized. It is \nunderstandable, as in 2005 there were (according to Linus) no good \ndistributed version control systems (SCMs). Also Karl Fogel writes in \npreface that much of material came from the five years of working with \nthe Subversion project, and Subversion is centralized SCM meant as \n\"better CVS\" and used itself as revision control system; any experience \ndescribed had to be with centralized SCM.\n\nThe distributed SCM is mentioned in footnote in section \"Comitters\" in \nChapter 8, Managing Volunteers:\n\n http://producingoss.com/producingoss.html#ftn.id284130\n\n  [22] Note that the commit access means something a bit different in\n  decentralized version control systems, where anyone can set up a\n  repository that is linked into the project, and give themselves commit\n  access to that repository. Nevertheless, the concept of commit access\n  still applies: \"commit access\" is shorthand for \"the right to make\n  changes to the code that will ship in the group's next release of the\n  software.\" In centralized version control systems, this means having\n  direct commit access; in decentralized ones, it means having one's\n  changes pulled into the main distribution by default. It is the same\n  idea either way; the mechanics by which it is realized are not\n  terribly important.\n\n\nI'm interested in your experience with managing projects using \ndistributed SCM, or even better first centralized then distributed SCM: \nis the above difference the only one? Linus has said that fully \ndistributed SCM improves forkability: \n\n \"Re: If merging that is really fast forwarding creates new commit\"\n Message-ID: <Pine.LNX.4.64.0611070841580.3667@g5.osdl.org>\n http://permalink.gmane.org/gmane.comp.version-control.git/31078\n\n  Time for some purely philosophical arguments on why it's wrong to have \n  \"special people\" encoded in the tools:\n\n  I think that \"forking\" is what keeps people honest. The _biggest_\n  downside with CVS is actually that a central repository gets so much\n  _political_ clout, that it's effectively impossible to fork the\n  project: the maintainers of a central repo have huge powers over\n  everybody else, and it's practically impossible for anybody else to\n  say \"you're wrong, and I'll show how wrong you are by competing fairly\n  and being better\".\n\nAccording to \"Producting Open Source Software\" it is very important \nfeature for an OSS project. See section \"Forkability\" of Chapter 4, \nSocial and Political Infrastructure (beginning of chapter):\n\n http://producingoss.com/producingoss.html#forkability\n\n  The indispensable ingredient that binds developers together on a free\n  software project, and makes them willing to compromise when necessary,\n  is the code's _forkability_: the ability of anyone to take a copy of\n  the source code and use it to start a competing project, known as\n  a fork.  The paradoxical thing is that the _possibility_ of forks is\n  usually a much greater force in free software projects than actual\n  forks, which are very rare.  Because a fork is bad for everyone (for\n  reasons examined in detail in the section called \"Forks\" in Chapter 8,\n  Managing Volunteers, http://producingoss.com/producingoss.html#forks),\n  the more serious the threat of a fork becomes, the more willing people\n  are to compromise to avoid it.\n\n\nBesides that, what are the differences between managing project using \ncentralized SCM and one using distributed SCM? What is equivalent of \ncommitters, giving full and partial commit access, revoking commit \naccess? How good support for tagging and branching influences creating \ncode and build procedure? Is distributed SCM better geared towards \n\"benovolent dictator\" model than \"consensus-based democracy\" model, as \ndescribed in OSSbook?\n\nThanks in advance for all responses\n-- \nJakub Narebski\nShadeHawk on #git\nPoland\n"},{"id":"40809","messageId":"Pine.LNX.4.64.0705011057130.29859@racer.site","threadId":"7901","inReplyTo":"200704300120.42576.jnareb@gmail.com","subject":"Re: \"Producting Open Source Software\" book and distributed SCMs","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-01T09:35:54Z","receivedAt":"2007-05-01T09:35:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 30 Apr 2007, Jakub Narebski wrote:\n\n> I have read lately classic book \"Producing Open Source Software. How to \n> Run a Successful Free Software Project\" by Karl Fogel (2005).\n> \n> Among others, author advocates using version control system as a basis \n> for running a project. In \"Choosing a Version Contol System\" he writes:\n> \n>   As of this writing, the version control system of choice in the free\n>   software world is the Concurrent Versions System or CVS.\n\nBack then, it was. I ran all my projects on CVS. Then came along Git. I \ntried to keep up with it, but had to quit for day-job reasons. When I came \nback, Git was already so good that I switched almost everything over.\n\n> The distributed SCM is mentioned in footnote in section \"Comitters\" in \n> Chapter 8, Managing Volunteers:\n> \n>  http://producingoss.com/producingoss.html#ftn.id284130\n> \n>   [22] Note that the commit access means something a bit different in\n>   decentralized version control systems, where anyone can set up a\n>   repository that is linked into the project, and give themselves commit\n>   access to that repository. Nevertheless, the concept of commit access\n>   still applies: \"commit access\" is shorthand for \"the right to make\n>   changes to the code that will ship in the group's next release of the\n>   software.\" In centralized version control systems, this means having\n>   direct commit access; in decentralized ones, it means having one's\n>   changes pulled into the main distribution by default. It is the same\n>   idea either way; the mechanics by which it is realized are not\n>   terribly important.\n> \n> \n> I'm interested in your experience with managing projects using \n> distributed SCM, or even better first centralized then distributed SCM: \n> is the above difference the only one?\n\nIn my experience, the offline mode has been a huge advantage. For example, \nin one project I work together with people from three different countries, \nsome of them traveling quite a bit. I sold Git solely on the \ntransportability. One of them was so happy that he switched over most of \nhis projects, too.\n\nBTW that is the common way I see: once people get hooked, they not only \nconvert their existing projects to Git, but they use cvsimport a lot more, \nand they start to manage configuration settings, documents, pictures, etc. \nwith Git, because it gives rise an easy backup mechanism.\n\nAnother difference between central and distributed operation I see is the \nworkflow. With Git, you can commit much more often. For example, when \nworking with Sourceforge's CVS (which _was_ comparable with the speed of \ncorporate SourceSafe repos), I would always think about committing (and \nhaving a coffee), or rather combine these changes with the next ones.\n\nObviously, committing more often leads to a much nicer repository \nstructure, making it much easier to get into the code for new developers. \nIt also makes it easier to get at bugs. And because it is so much faster, \nyou can actually do a \"git diff\" before committing, to make sure that you \ndid not leave in that stupid debug statement.\n\n> Linus has said that fully distributed SCM improves forkability:\n>\n> [...] \n> \n>   I think that \"forking\" is what keeps people honest. The _biggest_\n>   downside with CVS is actually that a central repository gets so much\n>   _political_ clout, that it's effectively impossible to fork the\n>   project: [...]\n> \n> According to \"Producting Open Source Software\" it is very important \n> feature for an OSS project.\n>\n> [...]\n> \n>   Because a fork is bad for everyone (for reasons examined in detail in \n>   the section called \"Forks\" in Chapter 8, Managing Volunteers, \n>   http://producingoss.com/producingoss.html#forks), the more serious the \n>   threat of a fork becomes, the more willing people are to compromise to \n>   avoid it.\n\nThis is a lousy argument, IMHO.\n\nWhy are forks bad? They are not. But if you \"learnt\" that merges are hard, \nthey are.\n\nIt is a pity that so many people were trained in CVS, and keep thinking \nsome of the lectures were true, when they are no longer.\n\nForks are good. In fact, we all \"forked\" with CVS as soon as we began \nhacking. Everybody who claims to never have started over from a fresh \ncheckout, or from an \"update -C\"ed state, is probably lying, or a bad \ndeveloper. Thinking about it, I believe that the difference between \nforking and branching is philosophical, not technical. You can always \nmerge a fork.\n\nAnd the thing is, you would not start hacking on some obscure feature, if \nthat happened completely in the open, for fear of being accused a complete \nmoron.\n\nWith CVS, that meant that you tried to get at a stage where others could \nsee that it was worth doing, before committing. Which makes for monster \ncommits. (\"The number of bugs is the _square_ of the number of changed \nlines.\") With Git, that problem is virtually not there.\n\n> Besides that, what are the differences between managing project using \n> centralized SCM and one using distributed SCM? What is equivalent of \n> committers, giving full and partial commit access, revoking commit \n> access?\n\nI have to admit that I drive one of my projects \"CVS\" style, with SSH \naccounts for all developers, who push into the same repo.\n\nBut that worked quite well up to now.\n\nIf I _had_ to restrict them, I'd probably do that by (temporarily) \nassigning a release engineer, and setting up some hook scripts in all \nrepos. But I don't believe in restriction when it comes to creativity.\n\n> How good support for tagging and branching influences creating \n> code and build procedure?\n\n> Is distributed SCM better geared towards \"benovolent dictator\" model \n> than \"consensus-based democracy\" model, as described in OSSbook?\n\nNot at all. I think the best example is kernel.org, where you find tons of \nforks. IMHO it is really helping the benevolent dictator cave into the \nconsensus-based model, since forks can be preferred at any time. Hey, even \nswitching from one to another upstream is just a git-pull away!\n\nCiao,\nDscho\n"},{"id":"40824","messageId":"20070501152342.GB26093@thunk.org","threadId":"7901","inReplyTo":"Pine.LNX.4.64.0705011057130.29859@racer.site","subject":"Re: \"Producting Open Source Software\" book and distributed SCMs","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-05-01T15:23:42Z","receivedAt":"2007-05-01T15:23:42Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, May 01, 2007 at 11:35:54AM +0200, Johannes Schindelin wrote:\n> > [...]\n> > \n> >   Because a fork is bad for everyone (for reasons examined in detail in \n> >   the section called \"Forks\" in Chapter 8, Managing Volunteers, \n> >   http://producingoss.com/producingoss.html#forks), the more serious the \n> >   threat of a fork becomes, the more willing people are to compromise to \n> >   avoid it.\n> \n> This is a lousy argument, IMHO.\n> \n> Why are forks bad? They are not. But if you \"learnt\" that merges are hard, \n> they are.\n> \n> It is a pity that so many people were trained in CVS, and keep thinking \n> some of the lectures were true, when they are no longer.\n> \n> Forks are good. In fact, we all \"forked\" with CVS as soon as we began \n> hacking. Everybody who claims to never have started over from a fresh \n> checkout, or from an \"update -C\"ed state, is probably lying, or a bad \n> developer. Thinking about it, I believe that the difference between \n> forking and branching is philosophical, not technical. You can always \n> merge a fork.\n\nThere's a confusion going on here between a \"fork\" meaning a branch in\nthe SCM sense of the word, and a \"Project Fork\" where there are two\ncamps competing for developers and users.  So for example, having\nkerenl developers develop using branches which are then merged into\nthe -mm tree and then into Linus tree --- Good.  In the\nsuspend-to-disk world, where we have *three* separate implementations,\nwith two in the mainline tree, and one very popular one, suspend2,\nwith features that niether of the in-mainline implementations have,\nand with Pavel constantly casting aspersions at Nigel because he's\nsplitting the development effort --- Not So Good.\n\nI prefer to use the term \"branch\" to talk about a SCM and development\nseries, and to use the term \"fork\" to talk about the political/project\nissues.  So for example, even though Ingo Molnar's CONFIG_PREEMPT_RT\npatchset has been a very long-running thing, it is constantly getting\nrebased against the kernel, and there is no expectation that this\nwould replace the mainline kernel.  That makes a code branch, and not\na fork.\n\nSo my suggestion is to let branches be branches, and to reserve fork\nfor when there is an attempt to compete for developer and user\nattention.  That is more or less the general understanding of the two\nterms, and trying to confuse the two only leads to confusion and a\ngeneral muddying of the waters.\n\nRegards,\n\n\t\t\t\t\t- Ted\n"},{"id":"40827","messageId":"Pine.LNX.4.64.0705011734460.4010@racer.site","threadId":"7901","inReplyTo":"20070501152342.GB26093@thunk.org","subject":"Re: \"Producting Open Source Software\" book and distributed SCMs","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-01T15:45:20Z","receivedAt":"2007-05-01T15:45:20Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 1 May 2007, Theodore Tso wrote:\n\n> On Tue, May 01, 2007 at 11:35:54AM +0200, Johannes Schindelin wrote:\n> > > [...]\n> > \n> > Forks are good. In fact, we all \"forked\" with CVS as soon as we began \n> > hacking. Everybody who claims to never have started over from a fresh \n> > checkout, or from an \"update -C\"ed state, is probably lying, or a bad \n> > developer. Thinking about it, I believe that the difference between \n> > forking and branching is philosophical, not technical. You can always \n> > merge a fork.\n> \n> There's a confusion going on here between a \"fork\" meaning a branch in \n> the SCM sense of the word, and a \"Project Fork\" where there are two \n> camps competing for developers and users.\n\nSo you agree! I said that it is a philosophical, and not a technical \nissue.\n\n> So for example, having kerenl developers develop using branches which \n> are then merged into the -mm tree and then into Linus tree --- Good.  \n> In the suspend-to-disk world, where we have *three* separate \n> implementations, with two in the mainline tree, and one very popular \n> one, suspend2, with features that niether of the in-mainline \n> implementations have, and with Pavel constantly casting aspersions at \n> Nigel because he's splitting the development effort --- Not So Good.\n\nBut why! Because Pavel is just ignoring reality. I always wondered why the \nwork of Nigel was never considered for inclusion, even if it was clearly \nsuperiour from a usability view point.\n\nAnd if it is usable, but not clean, then clean it up. Instead, Pavel seems \nto never even have considering casting his planet sized ego aside and \nadmit that his work is just not up to par with Nigel's, and start to \nclean up suspend2.\n\nSo in that case, I am even _more_ happy that forking is so easy, because I \ndid not _have_ to suffer all that much from people who cannot enter my \nflat because their head does not fit through the door, but I could just \nhappily use suspend2 and be fine.\n\nBTW the same goes for Reiser4, which is quite fast and flexible, and I do \nnot care at all about the ardent discussions around it.\n\n> I prefer to use the term \"branch\" to talk about a SCM and development \n> series, and to use the term \"fork\" to talk about the political/project \n> issues.  So for example, even though Ingo Molnar's CONFIG_PREEMPT_RT \n> patchset has been a very long-running thing, it is constantly getting \n> rebased against the kernel, and there is no expectation that this would \n> replace the mainline kernel.  That makes a code branch, and not a fork.\n\nI refuse to get involved in such a sophistic (not to be confused with \nsophisticated) discussion.\n\nI am _only_ interested in the technical side. Philosophical discussions, \nwhile fun when not taken too seriously, _can_ take all the fun out for me \nwhen the participants get too religious about their beliefs. So please, \nkeep me out of them.\n\nCiao,\nDscho\n"},{"id":"40832","messageId":"alpine.LFD.0.98.0705010829180.3808@woody.linux-foundation.org","threadId":"7901","inReplyTo":"200704300120.42576.jnareb@gmail.com","subject":"Re: \"Producting Open Source Software\" book and distributed SCMs","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-05-01T16:15:29Z","receivedAt":"2007-05-01T16:15:29Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 30 Apr 2007, Jakub Narebski wrote:\n> \n> Among others, author advocates using version control system as a basis \n> for running a project. In \"Choosing a Version Contol System\" he writes:\n> \n>   As of this writing, the version control system of choice in the free\n>   software world is the Concurrent Versions System or CVS.\n\nWell, I actually personally suspect that the original Linux method of \n\"patches + tar-balls\" is a perfectly valid method of source control \nmanagement, and in many ways preferable over CVS.\n\nSo no, I don't think using a version control system should be the _basis_ \nof running a project. Version control comes pretty far down the list, long \nlong after \"good taste\" and \"willingness to do things rather than talk \nabout them\", the latter of which tends to kill more hypothetical projects \nthan even CVS has ever done.\n\nThe _basis_ of an open source project is a good manager, a good idea, and \na realization that what matters most is _using_ the end result, rather \nthan the idea or discussions or \"cool features\".\n\nThe SCM becomes relevant only once you are far enough along that tar-balls \nand patches really don't work, and that might well take years.\n\n[ I'm really serious: I think a lot of the good practices that the kernel \n  project has gotten is exactly because of the \"patches rule\" mentality. \n\n  We now use real revision control, but I really *really* believe that \n  pushing patches around is a much better way of managing stuff than with \n  CVS or any other centralized model, because in the centralized model it \n  always ends up being about the \"core team\". In contrast, even if there \n  is a core team, if they just push patches around and discuss them as \n  such, non-core-team members are automatically basically all equal.\n\n  And avoiding the politics, and avoiding the \"five people are special\" \n  mentality is a *lot* more important than the limited and broken tracking \n  capabilities that CVS brings to the table.\n\n  So maybe I'm just in denial, but I really believe that the fact that the \n  kernel was basically maintained _without_ an SCM for a decade was \n  actually a *good* thing, considering the alternatives. ]\n\n> Further on much of examples of managing project and managing volunteers \n> revolves around the idea of \"commit access\", and it is assumed \n> implicitely that version control system is centralized.\n\nKarl Fogel is wrong. \n\nIt's an understandable mistake to do, since commit access is so important \nin a centralized environment, and he probably has never used anything else \n(even decentralized SCM's are often _used_ as centralized ones), but he's \nstill *wrong*. Fundamentally so:\n\n> The distributed SCM is mentioned in footnote in section \"Comitters\" in \n> Chapter 8, Managing Volunteers:\n> \n>  http://producingoss.com/producingoss.html#ftn.id284130\n> \n>   [22] Note that the commit access means something a bit different in\n>   decentralized version control systems, where anyone can set up a\n>   repository that is linked into the project, and give themselves commit\n>   access to that repository. Nevertheless, the concept of commit access\n>   still applies: \"commit access\" is shorthand for \"the right to make\n>   changes to the code that will ship in the group's next release of the\n>   software.\" In centralized version control systems, this means having\n>   direct commit access; in decentralized ones, it means having one's\n>   changes pulled into the main distribution by default. It is the same\n>   idea either way; the mechanics by which it is realized are not\n>   terribly important.\n\nThat's just making excuses. Yes, you can use the same words, and say that \nyou call the two TOTALLY DIFFERENT things \"commit access\", and then, \nbecause you've made two totally different things use the same term, you \nclaim that it's the same thing, and the differences aren't \"terribly \nimportant\".\n\nIt's like saying that a distributed (or threaded, for that matter) \nalgorithm and a linear algorithm both result in the same result, so the \n\"mechanics\" of the algorithm are not terribly relevant: they're both \nalgorithms.\n\nAnybody who has ever done any distributed algorithms realizes that the \nmechanichs are *hugely* important.  The difference between a distributed \nsituation and a centralized one is absolutely humongous. It changes \nliterally everything.\n\nDoes the fact that you *can* run a distributed algorithm on one machine \nmake it the same? No. Does the fact that the end result is called the same \nmake the two the same? No. It's a totally different model, and they share \nalmost none of the issues.\n\nWhen it comes to \"commit access\", not only is the term nonsensical in a \ndistributed environment, even if you want to use that term to describe the \nnotion of \"gets pulled into the next release\", it's not even TRUE.\n\nPeople like Andrew, Ingo, and Davem have what Karl would probably call \n\"commit access\". Andrew and Ingo have it even though they don't actually \neven use git to synchronize with me. But no, they don't actually get \npulled into the next release by default _anyway_ - there's always a \nconscious choice after the fact, rather than any implicit permission.\n\nI quite often tell maintainers that I won't pull their stuff, simply \nbecause the changes look too scary, and I'm too close to a release. Yes, \nit happens less often than me just silently pulling it, but that's not a \nsign of \"commit access\", that's a sign of the fact that the process \n_works_ in the first place. If we spent all our time arguing about it, and \npeople didn't just \"know\" how to behave, we'd never get anything done.\n\nSo that \"get pulled by default\" has _nothing_ to do with commit access, \nand everything to do with much higher-level process issues. And it's \nsomething that distributed development makes _possible_ in a way that the \ncentralized model with \"commit access\" simply does not.\n\nMiles and miles apart. And a very important distinction.\n\n(Btw, I'll argue that it's really important inside companies too, even \nwhen the source control in question is \"controlled\". When you do things \nlike validation, you shouldn't just allow \"commit access\" to the tree to \nbe validated. The validation group should maintain a tree that *they* \ncontrol, and getting things accepted into their tree should be just one \nstep on a \"release schedule\")\n\n> Linus has said that fully distributed SCM improves forkability:\n\nYes. There's two issues to forkability:\n\n - all real development happens as \"micro-forks\", and so you should make \n   that easy, whether it's an \"inside\" developer or somebody else who just \n   has a wild and crazy idea that might just work.\n\n - all real _honesty_ comes from a belief that the code *can* be forked, \n   and that even the original developer and/or top maintainer cannot force \n   his world-view on anybody.\n\nBoth of these are important, but the latter is important not because it \nshould be the \"normal case\", but just because the _knowledge_ that a fork \ncan happen should keep people honest.\n\nBig forks due to fundmanetal personality clashes (they are sometimes \nabout technology, but even when they are ostensibly about technology \nissues, they are often very much about strong personal ideas about that \ntechnology) are painful. But they should be painful not because of the SCM \nin question, but simply because handling personality issues is inherently \npainful.\n\nThe SCM shouldn't allow people to be a*-holes and control freaks.\n\nAnd I think Karl Fogel agrees with me on that. When he says \n\n   .. the more serious the threat of a fork becomes, the more willing \n   people are to compromise to avoid it.\n\nhe's right on the money, and I _think_ he meant it in the good way \n(compromise and trying to work with people is absolutely a _must_).\n\n> Besides that, what are the differences between managing project using \n> centralized SCM and one using distributed SCM? What is equivalent of \n> committers, giving full and partial commit access, revoking commit \n> access?\n\nSo here's what happens for the kernel:\n\n - we simply don't *have* commit access\n\n - there's no \"partial\", and there's not \"revoking\"\n\n - there are people I trust, but I don't trust them implicitly in the \n   sense that I give them the keys to my repository. If they go crazy, \n   there's nothing to revoke. NOTHING. If they go crazy, I just don't pull \n   from them. It's really rhat easy!\n\n - there are people I trust in certain areas, but that doesn't mean that \n   they can't make changes everywhere. It just means that I won't pull \n   unless I see that the changes are only to those areas.\n\n   And again, it's not an \"up-front\" decision: when people ask me to pull, \n   they tell me (by way of a diffstat) what they changed, and I can - and \n   actually do this, although mostly because it avoids mistakes - verify \n   it, because the pull always tells me what got changed.\n\n - In fact, what happens occasionally is that I pull something, and tell \n   people \"nope, that won't do\" and just discard their changes. It doesn't \n   happen every day, but it happened yesterday - David Miller (who is one \n   of the top developers) sent me a fix, I fetched it and told him it was \n   incomplete and I wouldn't pull until it was fixed.\n\nNotice? No partial commit access, no revoking, no granting. No politics. \nNo up-front \"you have rights\". Just a very basic issue: trust.\n\nAnd the nice thing about this is that if some subsystem needs to make \ntrivial changes to another subsystem, they don't need to ask for \npermission. They just do them, AND THEN THEY EXPLAIN THEM! And if they \nreally were trivial and obvious (and that's almost always the case), they \njust get pulled normally. No special dispensation.\n\nThis is somethign that a centralized repository with commit access \nfundamentally *cannot* do! If a maintainer who has partial commit access \nneeds to fix something else in order to make his subtree work, he's \nbasically screwed. He cannot commit his changes to *his* area, just \nbecause they depend on a fix to another persons area, and he cannot commit \nthat.\n\nCentralized SCM's are *fundamentally* broken. And the whole \"commit \naccess\" is very much part of that breakage. A distributed system doesn't \nhave it, doesn't need it, and is much much better off without it!\n\nThis is why I said Karl was totally off when he said that there's an \nequivalent to \"commit access\" in a distributed system too. It's just not \ntrue. Everything that people use \"commit access\" for just entirely goes \naway!\n\n> How good support for tagging and branching influences creating \n> code and build procedure? Is distributed SCM better geared towards \n> \"benovolent dictator\" model than \"consensus-based democracy\" model, as \n> described in OSSbook?\n\nI think branching is so fundamnetal to being distributed, that asking \nwhether good support for something like that is important for build \nprocedure is just not a valid question. It's like asking \"How important is \nwater to your social life?\" It's supremely important in the sense that \nwithout water, you wouldn't have a social life, but that's because you \nwouldn't _exist_ in the first place. But does that make water _directly_ \nimportant to your social life? Probably not, unless your life revolves \naround playing water polo with your buddies.\n\nSame goes for the benevolent dictator vs consensus-based model. I think \nthe distributed setup has advantages for both, and the advantages are much \nmore fundamental than anything direct. You can use distributed for either \nmodel, and in both cases, the tools a distributed system gives you are \njust different (and much better). \n\n\t\t\tLinus\n"},{"id":"40859","messageId":"200705012030.11747.jnareb@gmail.com","threadId":"7901","inReplyTo":"Pine.LNX.4.64.0705011057130.29859@racer.site","subject":"Re: \"Producting Open Source Software\" book and distributed SCMs","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-01T18:30:10Z","receivedAt":"2007-05-01T18:30:10Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Hi\n\nOn Thursday, 1 May 2007, Johannes Schindelin wrote:\n> On Mon, 30 Apr 2007, Jakub Narebski wrote:\n> \n>> Linus has said that fully distributed SCM improves forkability:\n>>\n>> [...] \n>> \n>>   I think that \"forking\" is what keeps people honest. The _biggest_\n>>   downside with CVS is actually that a central repository gets so much\n>>   _political_ clout, that it's effectively impossible to fork the\n>>   project: [...]\n>> \n>> According to \"Producting Open Source Software\" it is very important \n>> feature for an OSS project.\n>>\n>> [...]\n>> \n>>   Because a fork is bad for everyone (for reasons examined in detail in \n>>   the section called \"Forks\" in Chapter 8, Managing Volunteers, \n>>   http://producingoss.com/producingoss.html#forks), the more serious the \n>>   threat of a fork becomes, the more willing people are to compromise to \n>>   avoid it.\n> \n> This is a lousy argument, IMHO.\n> \n> Why are forks bad? They are not. But if you \"learnt\" that merges are hard, \n> they are.\n> \n> It is a pity that so many people were trained in CVS, and keep thinking \n> some of the lectures were true, when they are no longer.\n> \n> Forks are good. In fact, we all \"forked\" with CVS as soon as we began \n> hacking. Everybody who claims to never have started over from a fresh \n> checkout, or from an \"update -C\"ed state, is probably lying, or a bad \n> developer. Thinking about it, I believe that the difference between \n> forking and branching is philosophical, not technical. You can always \n> merge a fork.\n\nIIRC Compiz and Beryl (fork of Compiz) plan to be merged. Both projects\nuse git as SCM. We will see how this \"merge a fork\" will work.\n\nIn \"Producting Open Source Software\" Karl Fogel gives an example of\nGCC/EGCS fork, which resulted in \"fast forward\" merge (EGCS which was\nfork of GCC, became next version of GCC). Similar example is XFree86/X.Org\nfork; Linux distributions went from packaging XFree86 to packaging X.Org.\n\nBut for example GNU Emacs / XEmacs fork will never be merged, I think.\nSo not always you can merge a fork - you can try, unless codebase diverged\ntoo much.\n\n>> Is distributed SCM better geared towards \"benovolent dictator\"\n>> model than \"consensus-based democracy\" model, as described in\n>> OSSbook?\n>\n> Not at all. I think the best example is kernel.org, where you find\n> tons of forks. IMHO it is really helping the benevolent dictator cave\n> into the consensus-based model, since forks can be preferred at any\n> time. Hey, even switching from one to another upstream is just a\n> git-pull away!\n\nWhat is or is not a fork is a bit blurry in the world of distributed\nversion control systems. Is a clone of repository a fork? I think that\neverybody would agree that it is not. Is for example *-mm tree a fork?\nI'd say not. But I'd say that Beryl is a fork of Compiz...\n\n-- \nJakub Narebski\nShadeHawk on #git\nPoland\n"},{"id":"40862","messageId":"200705020027.41316.jnareb@gmail.com","threadId":"7901","inReplyTo":"alpine.LFD.0.98.0705010829180.3808@woody.linux-foundation.org","subject":"Re: \"Producting Open Source Software\" book and distributed SCMs","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-01T22:27:41Z","receivedAt":"2007-05-01T22:27:41Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> And the nice thing about this is that if some subsystem needs to make \n> trivial changes to another subsystem, they don't need to ask for \n> permission. They just do them, AND THEN THEY EXPLAIN THEM! And if they \n> really were trivial and obvious (and that's almost always the case), they \n> just get pulled normally. No special dispensation.\n\nActually Karl Fogel wrote in \"Producting Open Source Software\" that he\nrecommends and uses 'soft' partial commit access; it means that committing\nis restricted to a part of project for some by a guideline, but is not\nenforced by the tool (by SCM).\n\nP.S. I recommend actually reading the book (at http://producingoss.com)\ninstead of relying on my understanding of it.\n\n-- \nJakub Narebski\nShadeHawk on #git\nPoland\n"},{"id":"40866","messageId":"alpine.LFD.0.98.0705011532400.3808@woody.linux-foundation.org","threadId":"7901","inReplyTo":"200705020027.41316.jnareb@gmail.com","subject":"Re: \"Producting Open Source Software\" book and distributed SCMs","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-05-01T22:45:18Z","receivedAt":"2007-05-01T22:45:18Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 2 May 2007, Jakub Narebski wrote:\n> \n> Actually Karl Fogel wrote in \"Producting Open Source Software\" that he\n> recommends and uses 'soft' partial commit access; it means that committing\n> is restricted to a part of project for some by a guideline, but is not\n> enforced by the tool (by SCM).\n\nOh, absolutely. Except that really does require a lot of trust up front, \nwhich is the problem with commit access to begin with - you automatically \nhave a very clear (and *big*) difference between insiders and outsiders, \nand there is no \"gradual\" way to move from one to the other.\n\nSo yes, for practical reasons, \"commit access\" really is almost always an \nall-or-nothing thing for most centralized setups, because nothing else \nreally works. And when it isn't, it's just a horrible horrible pain in the \n*ss.\n\nWhat people do instead of commit access is to set up triggers to notify \npeople about certain subsystems being modified. Which is a good idea, but \nit's really a totally different thing.\n\n> P.S. I recommend actually reading the book (at http://producingoss.com)\n> instead of relying on my understanding of it.\n\nIt actually looks like a fine book, even though I think Karl is totally \noff in not seeing the big difference between centralized and distributed. \n\nI saw it at the local Borders, and considered buying it. I didn't even \nrealize that it apparently is downloadable too.\n\nAnd it talks about a lot of other things than just SCM's.\n\n\t\t\tLinus\n"},{"id":"40867","messageId":"alpine.LFD.0.98.0705011547080.3808@woody.linux-foundation.org","threadId":"7901","inReplyTo":"200705012030.11747.jnareb@gmail.com","subject":"Re: \"Producting Open Source Software\" book and distributed SCMs","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-05-01T23:13:10Z","receivedAt":"2007-05-01T23:13:10Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 1 May 2007, Jakub Narebski wrote:\n> \n> In \"Producting Open Source Software\" Karl Fogel gives an example of\n> GCC/EGCS fork, which resulted in \"fast forward\" merge (EGCS which was\n> fork of GCC, became next version of GCC).\n\nThe egcs fork was a total disaster, and a big part of that was CVS and the \ntight control of the gcc tree. \n\nIt took _years_ for people to get so fed up with the gcc maintenance that \nthe egcs tree happened at all, and it was a prime example of how *painful* \nCVS makes this, and how it allowed the gcc maintainers to do a really bad \njob, and ignore a whole lot of major problems simply because the whole gcc \nsetup was so hard to get into.\n\nSo yes, the egcs fork is a great example. It was not only a required (and \nvery good) fork, but it is _also_ an example of a setup where all the \ninfrastructure made the fork take a lot longer to materialize and be a lot \nmore painful than it should have been.\n\n> But for example GNU Emacs / XEmacs fork will never be merged, I think.\n> So not always you can merge a fork - you can try, unless codebase diverged\n> too much.\n\nIn all honesty, I don't think any tools would help there. Git can make \nmerging easier, but it cannot solve the fundamental differences in \npersonality and it can't help with ten years of differences. Git tries to \nmake merging easy by making it happen all the time, and thus the git \nmerge capability really depend on changing the *model*. But git cannot \nreally help you all that much if you have a decade of split, and the \ncodebases just don't look similar any more..\n\n(Not entirely true: git obviously does make merging easier, since people \nhave piped up to say that they imported branches from SVN just to merge \nthem in git and push the result back to SVN. So git _does_ help on the \npure technical side too, but I think the even more important part is how \ngit tries to encourage the model to be that one or both sides just merge \noften enough that the merges _stay_ easy).\n\n> What is or is not a fork is a bit blurry in the world of distributed\n> version control systems. Is a clone of repository a fork? I think that\n> everybody would agree that it is not. Is for example *-mm tree a fork?\n> I'd say not. But I'd say that Beryl is a fork of Compiz...\n\nWell, the -mm tree is a fork, but perhaps the difference is that the \n_intention_ is to merge back.\n\nWe've had \"real forks\" in the kernel community too. Vendor branches for a \nwhile tended to be real forks - not because the vendors didn't want to \nmerge back, but simply because they didn't have the capability and \ncommitment to do so. That's changed, partly because 2.4->2.6 was so \npainful for some of them.\n\nAnd the VM people have had real forks. The -aa tree wasa real fork in the \n2.4.x timeframe.\n\nSo I think the reason kernel people don't really think about \"-mm\" as a \nfork is that we've tended to be pretty amicable about the forks, whatever \nthe intention was. I personally encourage them, for example, in ways that \nmost other bigger open source projects do not. That makes it easier \npsychologically to fork, but more importantly, it also makes it easier to \njoin back again, because there was generally no hard feelings, just \ndifferences of opinion on technical matters that didn't get to be _too_ \npersonal.\n\nSo to _me_, the big issue is not so much forking, but joining it all back \n(ie merging). Forking should be trivial, and not even worthy of any real \ndiscussion. It should be a daily event, and sure, you'd expect the small \nforks to heavily outnumber the big ones, but none of that really matters \nif you just consider forking to not be a big deal - and always realize \nthat joining back is where the interesting stuff happens!\n\n\t\t\tLinus\n"}]}