{"thread":{"id":"913","subject":"[OT] mutually supervised developers","startedAt":"2005-06-11T21:19:31Z","lastAt":"2005-06-12T11:47:49Z","messageCount":3,"participants":["Junio C Hamano","Linus Torvalds","David Roundy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"4883","messageId":"7vy89gsiak.fsf@assigned-by-dhcp.cox.net","threadId":"913","inReplyTo":null,"subject":"[OT] mutually supervised developers","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-11T21:19:31Z","receivedAt":"2005-06-11T21:19:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I think this is somewhat offtopic here, but I was wondering:\n\n - if a development model like this would make sense,\n\n - and if so if we would want GIT to support such a model,\n\n - and if so if the current GIT already offers such support,\n\n - and if not what kind of primitives at the core layer we would\n   need to add.\n\nLet's assume that a project is co-managed by a handful top-tier\ndevelopers and has an active development community.  There is\n_the_ public repository that all users consider the canonical\nstarting point to base their work off of.  It would be like -git\nsnapshot tree or -mm tree in Linux 2.6 kernel.\n\nThese developers are all active in the community, and at times\nare overenthusiastic.  Their own changes are usually quite good,\nthey also have good taste when accepting outside patches, but\nthey all tend to commit not-so-well-thought-out crapola of their\nown from time to time to their own repository.\n\nI am wondering if the world would be a better place if this\nfictitious project sets up public repositories in the following\nway:\n\n (1) each developer's own repository is public;\n\n (2) these developers pull from each other \"only good stuff\",\n     rejecting things he or she feels questionable.  Let's\n     forget that current GIT does not give a direct support for\n     cherrypicking for now.\n\n (3) the public canonical repository is updated to contain the\n     intersection (_not_ union) of these developer repositories.\n     Let's also forget that current GIT does not have automated\n     way to do such a thing.\n\nThis would give each developer an \"adult supervision\" by all the\nother developers, because any stuff that somebody finds\nquestionable will not be included in the \"intersection\".  The\npublic canonical repository is essentially to contain the\ncommunity \"concensus\".\n\nApplying the above outline literally is inpractical in that it\ngives any slow (or just otherwise busy) developer an unintended\n\"veto\" power to freeze the canonical tree, so the management of\nthe canonical repository part may need to be tweaked with\nsomething like majority rule, but the basic idea is to help\npeople get mutual supervision to prevent them from spreading\ncrap they may later regret.\n\nWould people find something like this arrangement workable and\nworthwhile?\n\n"},{"id":"4885","messageId":"Pine.LNX.4.58.0506111612140.2286@ppc970.osdl.org","threadId":"913","inReplyTo":"7vy89gsiak.fsf@assigned-by-dhcp.cox.net","subject":"Re: [OT] mutually supervised developers","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-11T23:14:38Z","receivedAt":"2005-06-11T23:14:38Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 11 Jun 2005, Junio C Hamano wrote:\n> \n> I am wondering if the world would be a better place if this\n> fictitious project sets up public repositories in the following\n> way:\n> \n>  (1) each developer's own repository is public;\n> \n>  (2) these developers pull from each other \"only good stuff\",\n>      rejecting things he or she feels questionable.  Let's\n>      forget that current GIT does not give a direct support for\n>      cherrypicking for now.\n> \n>  (3) the public canonical repository is updated to contain the\n>      intersection (_not_ union) of these developer repositories.\n>      Let's also forget that current GIT does not have automated\n>      way to do such a thing.\n\nI've thought about it, but one problem ends up being the history.\n\nEven if both developers have the same patches, they may not have gotten \nthem in the same order, which means that it's basically impossible to \nretain history when doign an intersection. Unions are different - we can \njust add the new history when we create a union.\n\n> Would people find something like this arrangement workable and\n> worthwhile?\n\nIf you can explain how it would actually work.. \n\n\t\tLinus\n"},{"id":"4894","messageId":"20050612114745.GA9670@abridgegame.org","threadId":"913","inReplyTo":"Pine.LNX.4.58.0506111612140.2286@ppc970.osdl.org","subject":"Re: [OT] mutually supervised developers","fromName":"David Roundy","fromEmail":"droundy@abridgegame.org","sentAt":"2005-06-12T11:47:49Z","receivedAt":"2005-06-12T11:47:49Z","isPatch":false,"sender":{"key":"droundy@abridgegame.org","avatar":"https://gravatar.com/avatar/e8bcfd76f63303732bdfcdba6fc8ac6ccdff8f5a224a25ffaca24bd8a4c4571f?d=mp&s=160"},"body":"On Sat, Jun 11, 2005 at 04:14:38PM -0700, Linus Torvalds wrote:\n> On Sat, 11 Jun 2005, Junio C Hamano wrote:\n> > \n> > I am wondering if the world would be a better place if this\n> > fictitious project sets up public repositories in the following\n> > way:\n> > \n> >  (1) each developer's own repository is public;\n> > \n> >  (2) these developers pull from each other \"only good stuff\",\n> >      rejecting things he or she feels questionable.  Let's\n> >      forget that current GIT does not give a direct support for\n> >      cherrypicking for now.\n> > \n> >  (3) the public canonical repository is updated to contain the\n> >      intersection (_not_ union) of these developer repositories.\n> >      Let's also forget that current GIT does not have automated\n> >      way to do such a thing.\n> \n> I've thought about it, but one problem ends up being the history.\n> \n> Even if both developers have the same patches, they may not have gotten\n> them in the same order, which means that it's basically impossible to\n> retain history when doign an intersection. Unions are different - we can\n> just add the new history when we create a union.\n\nRight, cherry picking and history don't go well together--which is why\ndarcs doesn't normally store a real history (although it can do so--you\njust can't keep certain portions of the history unless you accept the\npatches involved).\n\nThere are also issues in defining the intersection of all patches.  Ideally\nif you take the union of that intersection with one of the original\nrepositories, you'd get that same repository back, but most naive\nimplementations of union/intersection won't have that property, which would\nlead to confusion and inconvenience.\n\nThis sort of workflow would actually be pretty easy to implement in darcs,\nif someone were interested.\n\nOn Sat, 11 Jun 2005, Junio C Hamano wrote:\n> Would people find something like this arrangement workable and\n> worthwhile?\n\nI think the biggest issue would be the one mentioned about the problems\nwith a single lazy developer.  But I think rather than some sort of\nmajority rule (or \"if three developers think it's okay, then it's okay\"),\nkeeping the number of relevant developers down would make sense.  This also\nmakes sense in that unless you've got seriously dedicated developers, you\ndon't want to force everyone to read every patch.  I think if you went with\na system like this and wanted many maintainers involved, it would probably\nbest to organize things hierarchically.\n-- \nDavid Roundy\nhttp://www.darcs.net\n"}]}