This is the fourth post in our series about integrating with a 3rd party developer tooling provider:

With our plan to create modular integration points for our tooling options, we have a few clear steps for moving forward:

Phase 1: Prep work

  • Deprecation of password authentication for Git, since many external tooling services no longer support it.
  • Working with core to provide compatibility for semver versioning for contrib, both because this is needed for Composer, and because all of the third party developer toolsets we are considering have begun to standardize on semver.

Phase 2: Initial implementation, replacing current features

  • Replacement of custom, bespoke Twisted Git daemon with standard Bitbucket repositories.
  • Replacement of unmaintained CGit with supported Bitbucket code viewing.

Phase 3: New features

  • Integration of merge request 'hook' into issue queues, to allow contributors to use a pull request workflow instead of patches.
    • Modular - to be used with Bitbucket for now, but potentially another solution when more mature.
  • Integration of code review 'hook' into issue queues, to give us powerful inline code commenting tools.
    • Modular - to be used with Bitbucket for now, but potentially another solution when more mature.

Phase 4: Implement Hybrid Integrations for other toolsets

  • Updating project page integrations such that those projects which are already hosted on third party tools such as GitHub or GitLab (for example, Drush) can easily login with SSO, synchronize their repositories, and choose the canonical home of their issues.

On-going: Evaluation

  • Re-evaluate other tooling solutions as blocking issues are resolved and their feature-sets evolve.

So that's the update!

In short: after more than a year's evaluation of the current leaders in open source tooling solutions, including direct collaboration with several of those teams, we are going to focus on making modular to integrate with the best tooling solution as it develops. For now, we will be implementing key improvements for Drupal developers using Bitbucket for our repository hosting, code viewing/review, inline editing, and merge requests - integrated with the existing project pages and issue queues.

We'd like to thank the following people for their involvement in this initiative at various times through the process:

Drupal Association Staff

The Technical Advisory Committee (TAC)

Members of the community

The teams of our potential partner organizations

Each of these teams is committed to serving open source and we thank them for their collaboration during our evaluation process:

  • GitHub
  • GitLab
  • Atlassian/BitBucket


jhodgdon’s picture

After reading through this entire post series, I'm very impressed with the thought that has gone into this, and excited for the Infra team to have a more maintainable infrastructure, and for the core/contrib developers to have merge requests and especially online code reviews.

I hope that it comes to pass soon -- and thanks to everyone who contributed to this roadmap (and who will contribute to its implementation).

nod_’s picture

It looks great. Can't wait!

andypost’s picture

Where issue links to follow?!

MustangGB’s picture

Looks good, particularly liked the inline editing idea. What would be even more amazing is if further down the line each issue could have it's own spin-off site, for example something like with an live editor for each issue.

gabesullice’s picture

This is awesome. I'm really excited and really impressed (but not surprised) by the thorough and thoughtful evaluation.

I'd love to help out with this, especially if I could help preserve/improve a CLI-based workflow.

mlhess’s picture

If anything this will be more CLI based as you will have branches, I think the only gui thing needed will be to create workspaces, but depending on the implementation, that could be an API, git command as well.

gabesullice’s picture

Awesome, that was exactly my hope.

ar-jan’s picture

This is a very well-reasoned evaluation of the options.

heddn’s picture

Nice to see a plan. Let's start moving in it!

frob’s picture

I was totally prepping a "What the hell, no confidence" type of comment. But this was very well thought out. 

Does semver for contrib act as a blocker for moving? I could see that taking a while.

hestenet’s picture

Strictly speaking we may be able to work around it, I will need to dive more deeply back into the implementation details to give a more thorough answer. That said, it would be *great* if we could get core and contrib on a consistent versioning schema to save us from building a hack to deconstruct later.

Tim L
Drupal Association - Director, Engineering

marvil07’s picture

Thanks for the thorough work and describing here in the detail the evaluation. It points clearly on the reasoning behind the decisions. I really appreciate it!

For now, I opened one ticket to support bitbucket URLs from versioncontrol, #2932504: Add a webviewer_url_handler plugin for self-hosted bitbucket URLs, a small step related to phase 2.

hestenet’s picture

Thank you, Marco! I knew I had forgotten someone from my list of credits. Appreciate your collaboration back at DrupalCon.

Tim L
Drupal Association - Director, Engineering

benjifisher’s picture

Thanks to all who have been working on this.

That includes our (potential) partners at GitHub, GitLab, and Bitbucket. As a member of the Drupal community, I am both grateful to and flattered by their eagerness to work with us. I would like to see a few of these individuals added to the official thanks on this page.

PCate’s picture

Is there a initial timetable planned for each phase?

hestenet’s picture

Not just yet, but we'll hope to update the D.O roadmap with our targets as we get further into implementation planning.

Tim L
Drupal Association - Director, Engineering