No documentation (not possible?) to add plugins to Trac

[fireproofsocks]

When developing a plugin, it's normal to set up a bug-tracker of some sort. I have found no documentation on how to do this using THIS bug tracker: trac. I've noticed that SOME plugins have support here, but nobody I've talked to knows how to get their custom plugins added to this bug tracker, which means that most of the plugins in the repository have no official bug tracking in place. That's a huge disservice to the community because only a fraction of those developers have the wherewithal to set up their own bug trackers.

This ticket is to request:

1. Access to trac for all plugin developers
2. Thorough documentation on how to get this set up for any new plugin authored
3. Ideally, incorporate this in a standardized way for all plugins so the authors don't have to do any extra footwork.

[nacin]

There does exist a Trac: ​http://plugins.trac.wordpress.org. The only plugins that are managed on this Trac instance are the importers.

Problem is, the plugins trac doesn't scale to 13,000 plugins. Otto and I have been discussing some ways to start over and make it more viable, but we're not sure yet how we'd do it.

[Otto42]

Getting the plugins trac working properly is indeed on my todo list.

[bpetty]

Lately I've assumed this wouldn't be much of a problem whenever Extend added support for plugins hosted on GitHub (which does need to happen at some point soon), where I'm sure tons of plugin authors would prefer to handle issues as well. Of course it could still use a ticket reporting system for plugins not hosting on GitHub still.

In the mean time though, it's still possible to develop plugins on GitHub (or elsewhere... maybe Google Code or even some other self-hosted tracker?) with issues enabled, and just link there from the plugin description.

[Otto42]

bpetty: Extend-Plugins will *not* be adding support for GitHub.

Extend-Plugins is a hosting site, not a listing site, and any plugins we have in the Plugins listing we will also be hosting. We will not add integration with a third-party repository anytime soon.

[bpetty]

Many of the plugins listed on WP.org already are hosted, written, and published on GitHub while manually being pushed to WP.org SVN, and the number of plugins doing that is growing. Why wouldn't Extend make that process more transparent and easier to use? It exists for plugin authors just as much as it's for users looking for plugins.

[Otto42]

The need to push the code into our SVN for a release system won't be changed. Again, Extend-Plugins is a hosting site, not a listing site. Ultimately, .org will retain control over the code it serves to users.

Eventually, support may be added for bug tracking and such, mostly in the form of links to other places, but this only will be for non-essentials. The code still must be in the .org system to be hosted by .org.

[bpetty]

Replying to Otto42:

The need to push the code into our SVN for a release system won't be changed. Again, Extend-Plugins is a hosting site, not a listing site. Ultimately, .org will retain control over the code it serves to users.

Who says WP.org can't automatically update a local copy of the plugin code from a GitHub repository (or any remote git repository for that matter). All I'm talking about here is automating the workflow that everyone using git for version control does by hand right now in order to push it up to WP.org. I'm not saying the actual plugin ZIP files would be downloaded directly from GitHub, or that WP.org wouldn't still maintain a local repo (whether that's still an SVN repo, or a git repo, it doesn't matter).

[mltsy]

As a new plugin developer, I have just gone through the process of checking in a new plugin, which I have been developing in Github. I thought "Hey I suppose I should start tracking issues in the trac system provided with this new SVN repo instead of trying to host it in two places..." but when I tried, I came across several tickets like this one, basically saying that's not going to happen. So I decided I would stick with Github for issue tracking, etc.

If you aren't going to support a full stack of software for open-source repository development (and it has apparently been years since Trac has worked for plugins), you are forcing developers to use another system, such as GitHub, which does support the full stack. So, in that case, why not make it easier on them and add some automation to the process of migrating code from their outside repository to the SVN repository you require the code to be hosted in?

Perhaps you could just add a git endpoint on your server, which would scan the master branch for changes, and commit them to the SVN trunk? That way I could use the same git project on my local machine to push to both Github and WP plugins. Alternately, you could setup a URL that could be used as a post-commit hook on Github, so that any time I checked code into Github, the SVN repo would automatically be updated.

I suppose this is off-topic for this ticket - sorry! Maybe this integration warrants a new feature ticket?

[Otto42]

We will get around to it when we get around to it. If you want to have your issue tracking elsewhere for the time being, then that's fine. But for the moment, it is not on our highest priority of things to do.

And there are no plans to add git or GitHub integration of any kind at present. When there are, then we'll let you know.

[mltsy]

I wasn't trying to be antagonistic by saying I was tracking my issues elsewhere - just pointing out that I have no other option! And of course, I understand it's not high on your priority list - I was just hoping to prod it up a notch ;)

Since I, as a new developer, basically have no choice but to use some other system for maintaining my software (since Trac is not functioning for the WP Plugins repo), another fix would be to integrate with a system with functional issue tracking.

Basically, either way (whether you believe it's more worthwhile to fix Trac or develop a git integration), my point is that it is a more than trivial obstacle in the development and publishing workflow and the feedback cycle for WP plugins, not being able to publish code and maintain issues in the same place. So I'm surprised that it has been left for years without a fix or even any documentation or guidance for new developers.

[bpetty]

Migrated to ​#meta160.