On WordPress + Git

Can you believe it – we’ve made it through a State of the Word without anybody asking “when is WordPress moving to Git/GitHub?” You may, however, have caught a brief mention of issue trackers in relation to the Triage Team focus for 2019. While it’s very important to make the distinction between Git the version control system (VCS) and GitHub the service, as the answer usually goes, it’s understandably a continued area of interest. Many parts of WordPress have been developed using GitHub as the central tool, along with countless plugins and themes and even the WordPress book.

Here’s the tl;dr (but you should definitely keep reading after this): Changing things up doesn’t just mean “let’s make the GitHub mirror at WordPress/wordpress-develop the canonical and migrate Trac tickets over” – it means imagining what kind of change would be a net benefit to the core development process and eventually the entire .org ecosystem, and then finding the right tools to do it.

To that end, there is a group of people including myself (@helen), @desrosj, and @omarreiss who have been and will continue to be doing more coordinated research and planning around tooling. There is no current planned timeline nor is this a priority on top of the projects already enumerated for 2019, but any potential tooling change is being evaluated as it potentially relates to those projects, especially if it can better support phase 2 of Gutenberg development and the Triage Team.

This is not about chasing the latest and greatest or evangelizing a preference – it’s important to identify the goals we have for the project and what pain points we are experiencing. More specifically than “democratizing publishing”, in the core development process we should be aiming for diverse participation, a faster-but-steady pace of development, predictable and timely feedback cycles, and continuing to build user trust among users of all types. Recent pain points have been merges between branches (especially 5.0 back to trunk), JavaScript package updating, and continued participation when projects move from plugins and GitHub into core and Trac.

Roughly, here are some early thoughts on various moving pieces and potential future improvements.

Repositories and Workflows

  • SVN repositories would need to remain, essentially flipping the mirroring process to go from Git -> SVN, making SVN (and Git) repos on .org read-only
  • Should the core build process continue to be handled as-is or should we move to something like Travis?
  • Integration of more automated testing – visual regression, end-to-end, accessibility, performance
  • Identification of the ideal lifecycle of an issue and process for a pull/merge request – design, docs, review, testing, etc.
  • Identification of contribution workflows (contributor documentation, Git branching methodology, etc.)
  • Security tracking and releasing

Issue Tracker

  • Critical for a Triage Team to review existing issues and to remain active going forward
  • Potential for the bulk triage process to include migration from Trac to another tracker
  • Any issue migration should be determine on a case by case basis by the Triage Team in collaboration with component maintainers; the most automation that should happen is a tool that takes a list of Trac tickets and imports them elsewhere
  • Issue import process needs to take commenter attribution into account
  • Trac would remain in a read-only state
  • How are reports generated and used (i.e. is the built-in filtering capability enough in a given tool or will we need something more robust to support workflows)
  • Is the issue tracker still the best place for feature requests?
  • Implementation of issue templates
  • Identifying existing custom integrations and whether those problems still exist and still need to be solved after a move

Broader Ecosystem (later / bigger question mark)

  • Connectors from GitHub to .org plugin and theme repos (GitHub Actions-powered build+deploy)
  • Automated testing – sniffers, Tide, unit tests, WP and PHP compat testing, Theme Check
  • Aligning plugin and theme review teams

#git, #trac, #triage

Git mirrors for WordPress

I’m pleased to share we now have an official Git mirror for the WordPress core development SVN repository.

git clone git://develop.git.wordpress.org/

Read-only mirrors are also set up for a few other WordPress.org repositories, including BuddyPress, bbPress, and the old core.svn “build” repository:

git clone git://buddypress.git.wordpress.org/
git clone git://bbpress.git.wordpress.org/
git clone git://core.git.wordpress.org/
git clone git://glotpress.git.wordpress.org/

Make sure you use the git protocol (not http) and include the trailing slash.

Can you use develop.git.wordpress.org for core development? Yes! For all practical purposes, the SVN and Git repositories are now equals. Pick your poison; use whatever you’d like for all your development and deployment needs.

For creating patches: If you’re into the command line, simply use git diff — to be specific, git diff --no-prefix is ideal. This format is easily applied with patch, just like SVN diffs. For more, check out scribu’s post on contributing using git. Might also be a good time to plug grunt-patch-wordpress, a work in progress — help make it awesome, if you can.

With this mirror, we’ve applied some lessons we learned from previous experiences:

  • Tags for major releases receive an extra .0 (“3.8.0”, not “3.8”), making them compatible with tools requiring semver-like version numbers, and allowing branches to have their own namespace (“3.8”, not “3.8-branch”).
  • Committer data is pulled from WordPress.org.
  • The SSL versions of the SVN repositories are used.

Note that these Git repositories have different hashes than anything currently mirrored on GitHub. We never did break these hashes as promised a year ago. Next steps will be to figure out how to best mirror these to GitHub (and replace what’s there), which is complicated by now having old and new repositories for core development. Additionally, I’m sure we’ll find at least one glitch in this in a matter of a few days, so consider the next week or so a beta test.

Edit: Well, I mentioned the next week would be a beta test. We found an error (that didn’t take long) in how authors got synced over, so we’ll be breaking the hashes tonight.

There are a lot of other repositories on WordPress.org not yet mirrored. Notably: plugins and themes. These are massive multi-project repositories and will require a bit more investment.

#git

Git Mirror History Breakage

A few years ago, I started publishing a mirror of WordPress on GitHub. It was subsequently promoted to WordPress/WordPress. What I neglected to do, however, was provide an appropriate authors.txt file, until recently. That means that earlier commits are attributed to dummy e-mail addresses and as such cannot be associated with user accounts on GitHub. Considering the recent introduction of contributions on GitHub, this seems a shame. Also, if we were to move to Git in the future, we would probably want our official mirror to have the best possible data.

Proposed

That we re-run the git-svn import with a proper authors.txt file.

Upsides

We’ll have a proper Git mirror with good and consistent author data, that we can, if desired, use for a future migration to Git. Commits will be properly attributed in GitHub.

Downsides

This will break Git history. If you have a Git checkout of WordPress, either standalone or in a submodule, that’ll mean that you’ll have to rebase your master branch off of origin (or even better, blow the whole thing away and re-clone).

So: thoughts? Would this ruin your day?

#git, #github

For forking pleasure: http://github.com/…

For forking pleasure: http://github.com/wordpress/

#git, #github