I believe Cononical's launchpad was built to achieve such workflows. It came out of the need to create an integration platform taking upstream versions of software and applying Ubuntu-specific fixes. In the old days, before git and GitHub won, I liked their bug tracker way over GutHubs as it really supported these flows, where bugs are fixed not in the main repo but by some contributor first. But we'll, wrong bet on bzr ...

Of course, Launchpad is also terribly confusing.

I wonder if there has been any work on porting launchpad to work with git.

Yes, there has. Launchpad works fine with git today.

Oh, awesome. I was going to look at that later this afternoon. Cheers!

Launchpad is also incredibly opaque to people who don't use it often. It took me a very long time to find the actual release binaries and how to get the sources + build info for them. It was for some nginx modules in a PPA which depend on a newer nginx than what is stock in Ubuntu Trusty. Took literally half a day to get binary-compatible modules built from source (building dynamic modules and they must match all the configure flags of the nginx you're trying to inject them into).

I can see how that that experience would have been poor for you, but I think it's a rather unfair comparison when comparing to GitHub. It's apples to oranges. Launchpad does more than git hosting, merge proposals ("pull requests") and bug tracking; it also manages the build infrastructure of a distribution and the publication of distribution sources and built binary packages. You did get tangled up doing the latter, but the former case is the context of this discussion. GitHub, GitLab and Sourceforge all cannot even do the much more complex tasks for which you had a poor UX on Launchpad.

Indeed. Launchpad has an incredibly bespoke feeling -- it is very much intended for Canonical's particular use case and it's clear they don't intend to spend much time making the on-ramp terribly shallow for new users/admins. That said it certainly represents a massive amount of work and it has a number of compelling features.

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.

What's wrong with branches and folders? Why are upstream repositories needed? (My hunch is the answer is just "it's slow with that much code" to which I again say "not when GVFS is ready").

Not to say Linux should change their ways, just that I wouldn't adopt them as part of a company.

I think a big chunk of "why is the kernel's git workflow the way it is" is just "it'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". That said, one area I suspect the 'branches in a common repo' model will have trouble is access control. With the kernel's approach I can set up a tree for the Foo subsystem without needing to have any kind of privileged access to the 'official' kernel tree: whoever I send Foo pull requests to chooses to accept them, or not, case by case. I don't get to make unreviewed changes to other bits of code. (Disclaimer: I haven't looked at github's access control model, maybe it lets you lock down master?)

You can do kernel development with a "we give commit access out fairly freely" 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't historically been socially organised that way, and changing tools is easier than changing organisational structure.

> Disclaimer: I haven't looked at github's access control model, maybe it lets you lock down master?

It does. It's pretty easy to have specific branches with specific permissions.

I was thinking the same thing.

But then I realized that the advantage of multiple repos is that it is decentralized: anyone can start their own fork, and collaboration works similar to the official forks, and you don’t need any centralized administration.

Having everyone share a single giant monorepo sounds like you’ll need a lot of people to support the infrastructure. Microsoft can do that. Can the Linux community?

With a huge monorepo, you can easily archive everyones contributions. That’s probably important for Microsoft. It’s not important for Linus — he only cares about the stuff he merges.

Finally, multiple repos allow people to work on stuff privately, and only contribute back to the public when they are ready.

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's often not possible to merge those codebases into a single repo.

GVFS has been working for years, but it's not even used related to the linux kernel at all. It's actually a GNOME-thing.

I think it's referring to this: https://blogs.msdn.microsoft.com/devops/2017/02/03/announcin...

Not sure why people are downvoting you. Just because Microsoft decided to give an already-in-use name to an internal project doesn't mean that the original project no longer exists. https://wiki.gnome.org/Projects/gvfs

>to which I again say "not when GVFS is ready")

So they should base their decisions on the eventuality of some project being ready?

Some 'enterprises' love doing that sort of thing. One project gets behind or fails and there are so many cascading problems.

Why can't issues just be mime messages (think email-formatted messages) in a directory for each issue? You could even have an issue file that would contain the status, person actively working, &c and then the thread of discussion as the mime files.