Sync code to public svn repos

[tellyworth]

Currently the code is deployed from the private dotorg repo. It should be in the public meta repo instead.

What do we need to change in order to move it there? Are there blockers to that?

[iandunn]

Dion added Slack notifications for GitHub commits, which seems like it'd achieve the same goal, but in a better way.

If we moved to public SVN, people would only see the bulk "sync w/ git" commits, which don't have things broken into meaningful chunks, and don't link to issues.

[dd32]

I don't personally think syncing to meta.svn is of any benefit here, as Ian says, any sync commits would not convey the actual changes contained within, and just add extra noise - unless it's automated and every Git commit causes a sync'd SVN commit - the reverse of our SVN->Git flow.

For our deployment process, it's also better to sync to the private SVN, as it means fewer svn:externals (The primary reason our deployment process is so slow).

One of the problems we have historically had with syncing Github code to meta.svn, is that changes then start to happen on meta.svn, and never ported upstream, two sources of truth effectively. You can see this happening with WordPress/pattern-directory (Mostly my fault, but I usually remember to sync it upstream immediately) and even more so with WordPress/helphub (which is now significantly out of date, and needs to be marked as archived/readonly).

We have a similar problem with code that is primarily developed on dotorg private SVN (for example, the Photo Directory, or Profile enhancements) where it is never migrated to the public meta.svn repo, and are not visible to the wider set of contributors.

We're at an odd point here, where many developers are not wanting to use Trac & SVN for development, but where without migrating away from Trac we're splitting things into harder-to-track locations. For self-contained projects this works well, but with WordPress.org having many moving parts all interacting with one another...

Ideally, IMHO, we'd use one single development platform (Be it Trac+SVN/Git, Trac/GitHub+SVN/Git, GitHub+Git, or GitLab+Git/SVN). Unfortunately Tracs builtin Git support is not a replacement for Git{Hub,Lab}, it can be used to present Git repos within Trac and auto-close tickets, but it doesn't make working with PRs easy or transparent.