On 08/04/2016 05:58 PM, Johannes Schindelin wrote: > [...] > Even requiring every contributor to register with GitHub would be too much > of a limitation, I would wager. > [...]
Is it *really* so insane to consider moving collaboration on the Git project to GitHub or some other similar platform? * Many, MANY of the most prominent open-source projects are already using GitHub. Many potential contributors already know how to use it and already have accounts. Casual observers (e.g., people who only want to clone the repo and/or read issues and PRs) don't even need an account. * Even if you don't already have a GitHub account, it is vastly easier to create one than to set up our current contribution workflow: figure out the correct SMTP settings for your email provider, configure git-send-email, test it and work out the kinks, figure out how to use git-am (and even then, actually using git-am is a tedious chore for people who don't use an email client that can run it automatically) [1]. We've seen how difficult our current workflow is by observing GSoC candidates attempting to send their first patch. What we haven't seen is the invisible GSoC candidates and other potential contributors who never even get as far as attempting to send a patch. * Interactions that involve code are done using Git commands directly, via exchanging bona fide Git commits. Which means that... * Commits have unambiguous SHA-1s, which we can use when discussing them, linking to them, merging them, etc. It will no longer be a matter of detective work to find out whether a discussion is about v1 or v3 of a patch series, let alone v3 with some cleanups that were silently added by Junio. * Discussion of pull requests can be done either * via the website (super easy for beginners but powerful for experienced users), * by setting up email notifications for your account and replying to those emails, or * via an API. Such discussion is all in markdown, which supports light formatting, hyperlinks, and @-mentions. * GitHub creates permalink URLs for all of the important artifacts: commits, pull requests, pull request comments, etc. These all can be referenced easily from any discussion. This web of cross-links accumulates over time and adds a lot of context to discussions. * GitHub keeps spam under control. I admit that if we move to GitHub we would be vulnerable if the company turns evil or goes bankrupt. But is that really a bigger risk than we accepted by relying on Gmane (a one-person hobbyist operation) for many of our historical permalinks, which are now broken? In any case, each of us has a mirror of the code, and there are utilities for backing up other GitHub metadata. *If* GitHub becomes evil, there will be a lot of other open-source projects in the same boat, so I am confident that the tooling for salvaging such information will quickly become excellent. Currently we force potential Git contributors to learn an email-based workflow that is almost unique to this project, rather than steering them towards a workflow (Git plus, potentially, GitHub) that they probably already know, or if not is worth learning because the knowledge will carry across to most other open-source projects, not to mention their professional careers. We would want to set down guidelines for how we use GitHub. For example, we might insist that each version of a patch series (v1, v2, etc.) be submitted as a fresh pull request with references to the previous version(s) (which also automatically creates forwards links from the previous versions to the new version). We might want to set up some robots to help with repetitive activities, like style review, pinging the right people, etc. Junio, I'm very sensitive to the need not to decrease your efficiency. But isn't there a chance that this could *increase* your efficiency? Is it worth an experiment? Is the Git project really such a unique snowflake that we need to use a workflow (and force it on our contributors) that is different than the workflows used by most other open-source projects? Disclaimer: I work for GitHub, but in this email I'm speaking for myself. Michael [1] I concede that people who refuse on ideological grounds to use proprietary software will find this step insurmountable. Perhaps we could come up with a workaround for such people. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
