Know something about Github or Drupal.org? Please help flesh out the Drupal.org vs. Github feature list!
August 27: Here's an attempt at summarizing the high-points of discussion/research so far.
What's your idea?
Github has superior features such as Pull requests, forking projects, inline code editing, inline code commenting etc. that are far easier to understand for new contributors and more efficient for developers working with open source code daily. We should use drupal.org for things that it is good at: project releases, centralised repository of projects, the issue queue etc.
We should not host our own Git repositories and rather integrate our issue queue with Github pull requests and their API.
There is a similar proposal: Implement Pull requests on Drupal.org
What are the benefits?
Less time spent on building/maintaining our own Git infrastructure. Less code to upgrade during major version upgrades of Drupal.org. Lower barrier for people to contribute, higher visibility of Drupal code in the Github social ecosystem, more efficient contribution workflow.
- better git viewer
- integrated some dreditor features (comment on line level)
- inline editing of files
- linking issues
- pull requests
- private repos possible (we only use this for bluecheese)
- extensive rest api (how would we actually use this?)
What are the risks?
- Relying on a commercial entity that can change whatever they want without our consent. However, Github has earned the trust of many open source projects already. In the worst case scenario we have to move back our Github repositories back to drupal.org or choose another provider (Gitorious, Bitbucket, ...)
- Registering an account on *.drupal.org makes sense when you are a member of the Drupal community. Registering on Github and give away all your data (account data, activity, etc.) to an entity you do not particularly identify with might not.
- The Github Pull request workflow may not work so well for us because multiple people working on one pull request have to be granted access to the forked repository. Another solution is to send a PR to a fork.
- It is very easy to fork and it's questionable whether people would pull request back or just use their fork. But, people often have "forks" of Drupal modules locally currently. Would forks on Github change this one way or the other (i.e. are pull requests easier than patching?). May be already happening silently in d.o, see comment: https://groups.drupal.org/node/313068#comment-953538 and also: https://groups.drupal.org/node/313068#comment-953898
With the forking model it's very confusing to see which one is the 'real deal' and which is a fork.Solution: Keep d.o centralized project listing, as stated in the proposal. Publish in d.o project's page the link to the real repository. It is the model already used today. See comments: https://groups.drupal.org/node/313068#comment-954488 https://groups.drupal.org/node/313068#comment-953468 Counter: Solution does not address repository ownership transfer (via forking), and updating actual user sites to the new fork.
- For core development, already on drupal.org we have sandboxes and finding sandboxes is a huge issue. The issue queue - patch based development model makes everyone's work visible but when people fork, it's just not on the radar, you have no idea what's going on.
- Impact on long-term project involvement (Historically, we have seen less longevity and participation in any 'off-drupal.org' initiatives than those on drupal.org). It's unclear if Github would follow that same trend.
- Impact on code quality/moderation/spam control in the repositories (loss of 'git vetted user' permission check)
- Concept that 'all forks are created equal' will cause pain for new users and make it harder to manage projects on drupal.org. (i.e. transfer of repository ownership via a new fork, and challenge in updating drupal.org references/pointers; not to mention pointers for existing user sites which are not redirected).
- Adds complexity to packaging, distributions, whitelisted libraries,
download/usage tracking, automated testing, update manager, d.o project browser, project management, security advisories, etc.
- Significant development efforts required to break drupal.org repository ties and refactor to leverage github APIs, and potential burnout as this would be the same resources who have been involved in the D7 drupal.org migration.
- Github is not as accessible as drupal.org and we can't do anything to fix it
- Additional risks related to moving issue queues to github (which some have argued for in the comments -- a summary is in this comment: https://groups.drupal.org/node/313068#comment-954428):
- Impact on ability to host private security issues (security.drupal.org uses the project issue module now - we would need a similar system or to reinvent or flow for managing those issues)
- Inability to differentiate between bug/support/feature request issues (we can use tags, but that feels like a hack and might not be done consistently between queues)
- Inability to easily move issues between queues
- Impact on ability to moderate issues (e.g. blocking a troll account)
- Inability to upload files other than images to issues (don't make me query for how often this happens...) would result in hosting elsewhere and then linkrot when elsewhere goes offline.
- Forcing users who just want to report and get updates on issues onto a separate, unfamiliar site (where they will presumably have to log-in again).
How can we measure the impact of this idea? (metrics)
By the average time it takes to write a patch and get it commited. By the number of people contributing to Drupal core and Drupal projects. By the amount of time that would be saved maintaining our own Git infrastructure. By the amount of time that would be saved during major version upgrades of Drupal.org.
Who directly benefits from / will use this improvement? (target audiences)
Are additional resources available for discovery/implementation? (volunteer effort, financial backing, etc.)
In Gaelan's experience, GH has great support. Gaelan is trying to get them to weight in on this discussion.