tag:blogger.com,1999:blog-12913358.post6581460567506030670..comments2023-08-27T05:12:10.999-07:00Comments on PRNG: Pseudo Random Noise Generator: Commit Access: It's a Social ProblemGreghttp://www.blogger.com/profile/02475017701402788075noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-12913358.post-69465130541898741772009-03-05T05:14:00.000-08:002009-03-05T05:14:00.000-08:00I posted a similar idea on the python-dev list. I ...I posted a similar idea on the <A HREF="http://markmail.org/message/ecza7o3jnjczh4xx#query:python-dev%20dstanek+page:1+mid:hgb4tmfjtg7orxuh+state:results" REL="nofollow">python-dev</A> list. I was a little less radical in that I wasn't thinking that anyone who wanted access should get it, but I do find the idea interesting.David Stanekhttps://www.blogger.com/profile/11381604701662540021noreply@blogger.comtag:blogger.com,1999:blog-12913358.post-63508223714738416702009-03-05T00:41:00.000-08:002009-03-05T00:41:00.000-08:00It's almost a social problem, but not quite.Subver...It's almost a social problem, but not quite.<BR/><BR/>Subversion mixes two authorities. To do any serious work (which should be done in a branch) you also need authority to unilaterally push new versions. It's akin to giving someone your full banking information simply because they offered to pick up some coffee for you. Not only is it a significant and pointless risk, but having to evaluate and monitor that risk wastes a great deal of time.<BR/><BR/>The ideal social arrangement involves a lot of patch review, signing off on patch sets, communication, etc. DVCS simply supports that sort of flow, while SVN gets in the way.<BR/><BR/>(Incidentally, I'm suffering from SVN right now. I started fixing some bugs in an open source game and it's become non-trivial, so I've had to stop.)Adam Olsenhttps://www.blogger.com/profile/12472103461437043685noreply@blogger.comtag:blogger.com,1999:blog-12913358.post-42302754197711605352009-03-04T12:43:00.000-08:002009-03-04T12:43:00.000-08:00@Greg I like how you have framed this as a social ...@Greg I like how you have framed this as a social problem, but I see another situation which your analysis misses:<BR/><BR/>Many, perhaps most open source projects are dead or at least not actively maintained. Current DVCS tools make it trivial for anyone to pick up and start hacking away at long-forgotten streams of code, and making their changes public.<BR/><BR/>GitHub makes this process discoverable: looking at some project's mainline, you can also see any forks in the graph and follow the code's activity as it evolves away from its origin.<BR/><BR/>As the body of open source increases and more projects are orphaned and abandoned, this ability to branch without commit rights will become more important. "Not actively maintained" should not be equivalent to "RIP".Brian P O'Rourkehttps://www.blogger.com/profile/17945018891200270744noreply@blogger.comtag:blogger.com,1999:blog-12913358.post-67127501197515276292009-03-04T09:03:00.000-08:002009-03-04T09:03:00.000-08:00> However, I still believe it is no big deal to...> However, I still believe it is no big deal to ask to create a branch and provide commit access. If you're going to participate in a project, then one simple email is no big deal.<BR/><BR/>What you have to think about here is the marginal contributor; it really helps to think about this problem in economic terms.<BR/><BR/>I propose that sending an email to a mailing list when you're not well known on that list asking for commit access is a relatively high-cost action; you put yourself out there to guys you really respect, when you're not even sure that you're going to be able to help them by doing anything useful.<BR/><BR/>Let's say 1/100 people who will download your source will make useful contributions. If you make the cost to prepare to participate even a *little* high, you're much less likely to get that one than you are otherwise.<BR/><BR/>The solution? Lower the cost to get the code and hack on it, and focus on reviewing people's contributions.<BR/><BR/>It's easier to ask forgiveness than permission.Bill Millhttps://www.blogger.com/profile/10065077215311205545noreply@blogger.comtag:blogger.com,1999:blog-12913358.post-1234053180356148562009-03-02T07:33:00.000-08:002009-03-02T07:33:00.000-08:00@ben That's an interesting observation and thinkin...@ben That's an interesting observation and thinking about the projects I've worked with on GitHub, it seems very accurate.<BR/><BR/>@greg To take your "give anyone a branch who asks for it" suggestion to the extreme there should be a button that allows anyone to create a branch. No email required. Just automate the branch creation completely.<BR/><BR/>And about the "tracking work" issue in the DVCS world? I think it's a nightmare. When I find a git repository, I'm always wondering where the latest development might be happening. This is particularly a pain when the original author has abandoned the work.J. Aaron Farrhttps://www.blogger.com/profile/06668304178579943032noreply@blogger.comtag:blogger.com,1999:blog-12913358.post-32713122022621208362009-03-01T12:03:00.000-08:002009-03-01T12:03:00.000-08:00'Unpublished branch' (possible only in DVCS) gives...'Unpublished branch' (possible only in DVCS) gives ability to incrementally improve patch series, for example changing how it splits into commits, or correcting some error in the patch itself instead of adding fix two patches later. This requires rewriting history, which requires that history is not made public.<BR/><BR/>Of course it can be taken too far...Jakub Narebskihttps://www.blogger.com/profile/11847202568800326989noreply@blogger.comtag:blogger.com,1999:blog-12913358.post-81529781729023328662009-03-01T03:26:00.000-08:002009-03-01T03:26:00.000-08:00@Greg Stein: With centralized VCS you have (from w...@Greg Stein: With centralized VCS you have (from what you wrote) the choice between "get tarball, send patch" and "ask for commit access in a branch" (and further "full commit access", but it doesn't matter here). You miss a very important workflow: use distributed VCS to prepare <EM>series</EM> of patches, and send them to mailing list <STRONG>for review</STRONG>. In my opinion public mailing list is much better forum for review than some branch in centralized VCS plus perhaps some 'please review' / 'please pull' request.<BR/><BR/>@Ben Collins-Sussman: What about suggestion in seminal "The Mythical Man-Month" by Brooks that each group needs intergrator / maintainer; which IMHO in the DVCS world translates to one person, maintainer, applying patches and pulling from lieutenants trees into official repository.Jakub Narebskihttps://www.blogger.com/profile/11847202568800326989noreply@blogger.comtag:blogger.com,1999:blog-12913358.post-20241038565080267082009-03-01T02:26:00.000-08:002009-03-01T02:26:00.000-08:00@Jakub: agreed. I already gave DVCSs props for bet...@Jakub: agreed. I already gave DVCSs props for better handling of a single patch. When it gets more complicated (as you demonstrate), then a DVCS is even better.<BR/><BR/>However, I still believe it is no big deal to ask to create a branch and provide commit access. If you're going to participate in a project, then one simple email is no big deal. And hell... if people would get past the social problem, then <B>technical</B> assistance could be done to allow for a simple request/provide access workflow.<BR/><BR/>And I'm sure you realize that I'm not a fan of the concept "without showing your experiments to the world at large". It is <B>that</B> kind of offline, private development that I believe DVCS encourages to the detriment of Open Source communities and projects.<BR/><BR/>@sussman: very interesting point about the "each with their own repository". I can't help but believe that is an outgrowth of a mindset: fiefdoms, control, us vs them, etc. A project <B>still</B> has to have one Master repository that releases are cut from, but if all the work is pushed out to N repositories, then how does a newcomer every find out what is going on? How do you track work? How do you do continual review/feedback before the power-plant push of a set of changes? There needs to be a mechanism to point to those N repositories, and that implies <I>centralization</I>. Whether that is GitHub or some other system, there is always centralization.Greghttps://www.blogger.com/profile/02475017701402788075noreply@blogger.comtag:blogger.com,1999:blog-12913358.post-6469176944596776232009-03-01T02:14:00.000-08:002009-03-01T02:14:00.000-08:00The problem with "get tarball, send patch" approac...The problem with "get tarball, send patch" approach is that it work only if your change can be expressed well using single patch. If the change should be done (for easy review and for easy bisectability) as a series of patches (series of commits), then access to version control is very much required. Distributed VCS, without need to even ask to create branch, and without showing your experiments to world at large, lower barrier to entry.Jakub Narebskihttps://www.blogger.com/profile/11847202568800326989noreply@blogger.comtag:blogger.com,1999:blog-12913358.post-14645107625130735282009-02-28T13:04:00.000-08:002009-02-28T13:04:00.000-08:00If you're talking about a group of committers who ...If you're talking about a group of committers who already have access to a central repository -- then yes, I agree, DVCS adds little value beyond the occasional convenience of doing "offline" commits on a train or plane.<BR/><BR/>But as you mentioned in your post, IMO the really huge "value proposition" of DVCS is that it dramatically lowers the barrier for participation by non-committers . Emailing patches back and forth is so much more awkward than doing peer-to-peer "pulls" of changesets. By making the review process more pleasant and giving*everyone* the exact same version control tools -- committers or not -- it's dramatically easier to get outside contributions.<BR/><BR/>In theory, you'd think that lower this barrier would make projects "accelerate" in their ability to pick up core members... but oddly there seems to be a counter-force in the git community where the convention is that absolutely every participant keeps a permanent "private" repository. They take the pyramid-model to an extreme, where no 2 people ever work in the same repository. This seems to create a "monarch" mentality - every project is "owned" by one person, rather than an egalitarian set of committers. It worries me.Ben Collins-Sussmanhttps://www.blogger.com/profile/16129727804966707195noreply@blogger.com