<story><title>Why GitHub Can&apos;t Host the Linux Kernel Community</title><url>http://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html</url></story><parent_chain><item><author>rattray</author><text>Especially in a world where GVFS is a thing (not quite yet), I fail to see the advantage of a monotree over a monorepo with lots of branches and scripting around a MAINTAINERS file.&lt;p&gt;What&amp;#x27;s wrong with branches and folders? Why are upstream repositories needed? (My hunch is the answer is just &amp;quot;it&amp;#x27;s slow with that much code&amp;quot; to which I again say &amp;quot;not when GVFS is ready&amp;quot;).&lt;p&gt;Not to say Linux should change their ways, just that I wouldn&amp;#x27;t adopt them as part of a company.</text></item><item><author>clarkevans</author><text>As I understand, Daniel Vetter is proposing a &amp;quot;monotree&amp;quot; as a source code control pattern where a monorepo (and its branches) is not the primary place where development is done, but is rather where works are integrated from subordinate repositories.  In particular, he&amp;#x27;s asking for GitHub to support coordination (issues and pull requests) spanning upstream repositories that are indicated by a particular change request.&lt;p&gt;I was hoping to see discussion of the merits of this proposal here on HN... not a regurgitation of Torvalds&amp;#x27; positions and personal demeanor. What other projects  use a monotree? does it work well? How do those projects coordinate changes across subordinate repositories?</text></item></parent_chain><comment><author>pm215</author><text>I think a big chunk of &amp;quot;why is the kernel&amp;#x27;s git workflow the way it is&amp;quot; is just &amp;quot;it&amp;#x27;s a formalized and tooled-up equivalent of the preexisting organizational structure where everybody was emailing patches, submaintainers had kernel source trees on their local machines that they were in charge of, etc&amp;quot;. That said, one area I suspect the &amp;#x27;branches in a common repo&amp;#x27; model will have trouble is access control.  With the kernel&amp;#x27;s approach I can set up a tree for the Foo subsystem without needing to have any kind of privileged access to the &amp;#x27;official&amp;#x27; kernel tree: whoever I send Foo pull requests to chooses to accept them, or not, case by case. I don&amp;#x27;t get to make unreviewed changes to other bits of code. (Disclaimer: I haven&amp;#x27;t looked at github&amp;#x27;s access control model, maybe it lets you lock down master?)&lt;p&gt;You can do kernel development with a &amp;quot;we give commit access out fairly freely&amp;quot; model, of course (I think some of the BSDs are like that, again as historical accident of the cvs style tooling they used to use); but Linux hasn&amp;#x27;t historically been socially organised that way, and changing tools is easier than changing organisational structure.</text></comment>
<story><title>Why GitHub Can&apos;t Host the Linux Kernel Community</title><url>http://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html</url></story><parent_chain><item><author>rattray</author><text>Especially in a world where GVFS is a thing (not quite yet), I fail to see the advantage of a monotree over a monorepo with lots of branches and scripting around a MAINTAINERS file.&lt;p&gt;What&amp;#x27;s wrong with branches and folders? Why are upstream repositories needed? (My hunch is the answer is just &amp;quot;it&amp;#x27;s slow with that much code&amp;quot; to which I again say &amp;quot;not when GVFS is ready&amp;quot;).&lt;p&gt;Not to say Linux should change their ways, just that I wouldn&amp;#x27;t adopt them as part of a company.</text></item><item><author>clarkevans</author><text>As I understand, Daniel Vetter is proposing a &amp;quot;monotree&amp;quot; as a source code control pattern where a monorepo (and its branches) is not the primary place where development is done, but is rather where works are integrated from subordinate repositories.  In particular, he&amp;#x27;s asking for GitHub to support coordination (issues and pull requests) spanning upstream repositories that are indicated by a particular change request.&lt;p&gt;I was hoping to see discussion of the merits of this proposal here on HN... not a regurgitation of Torvalds&amp;#x27; positions and personal demeanor. What other projects  use a monotree? does it work well? How do those projects coordinate changes across subordinate repositories?</text></item></parent_chain><comment><author>swift</author><text>Sometimes a monotree is the only way. If your business model revolves around an open source core with some proprietary add-ons for paying customers, it&amp;#x27;s often not possible to merge those codebases into a single repo.</text></comment>