Last night I started integrating one of Dougal‘s plugins into a little WordPress-based app I’m building to help me keep track of HR/benefits related requests for my team.
Since I’m building the app as a theme, I dropped the plugin into the theme. It worked great, except the path to the CSS file wasn’t correct (since the code wasn’t living in the plugins directory). A quick poke around and I found the GitHub repo for the plugin, which I quickly forked, patched (by adding a filter), and submitted back as a pull request. This morning Dougal accepted the pull request. Done and done.
At the WordPress Community Summit I participated in a session about plugin continuity and development (see Abandoned Plugins). It naturally included discussion about how the various developers there build their plugins. Most1 of those present are hosting their primary development on GitHub and checking them in to the SVN repo on WordPress.org as a packaging step for distribution.
This is why. There just isn’t a WordPress community owned property that allows for this type of developer collaboration. I think it makes sense for the plugin and theme repositories on WordPress.org to adopt a “GitHub URL” meta property for projects.2 Until they do, I’m going to start adding it prominently to the README when I release new versions of my plugins.
Fellow WordPress developers, please collaborate on my plugins on GitHub. Most of them are under the Crowd Favorite account, a handful are on my account.
This post is part of the thread: Version Control – an ongoing story on this site. View the thread timeline for more context on this post.
RT @alexkingorg: Collaborative WordPress Development on GitHub http://t.co/KER1ldZi – completely agree
@jaredatch @alexkingorg Except then I have to check in to Bitbucket, Github AND http://t.co/XgKzVXNZ. Maybe make it a DVCS URL?
@zamoose thats a good point, but I think the assumption is most people use GH as a collaboration tool /cc @alexkingorg
@alexkingorg I love your idea about the Github URL for plugins, but one thing: you can’t follow an organization on Github
@norcross but groups still have repos, like https://t.co/04HaBysf. I imagine you would list your repo URL for each plugin /cc @alexkingorg
@jaredatch @alexkingorg that’s correct. I was just noting in his post where he said ‘come collaborate with us’.
Uh huh… Come up with a good solution to using Git on Windows, and then you have something. I don’t use Git or GitHub, specifically because the entire experience is basically terrible on Windows machines.
– Command line Git uses CygWin, which everybody will agree with is total junk.
– TortoiseGit just flat out doesn’t work, as far as I can tell. They may have improved it recently, I haven’t checked in a few months.
– GitHub’s own app works, but it’s like source-control-for-children and not a real developer tool. It’s more of a bad-joke than anything useful.
The main problem I have with GitHub in particular is that they want you to use their website for most things. I have a problem with that sort of centralization, in that I don’t want to use a webpage to do developer tasks, I want to use my IDE of choice, or native apps on my system. It doesn’t help that I dislike the overall design of github.com, I grant you. It’s far too Mac-like for my tastes.
BTW, anybody who replies with “use a different operating system” will simply be ignored. I like my development environment, and most of that is on Windows. I’m not going to change my dev environment for any source-control mechanism, or any website. It’s up to them to change to accommodate me (and the 95% of the rest of the world not using Macs for development), IMO.
If you develop on GitHub, then that’s fine. But your only contributors will be other people using GitHub, which doesn’t include me because GitHub, IMO, sucks rocks as a developer tool. I’ve been writing code professionally for the better part of 20 years now, and if they are only planning to cater to the new-age hippy-dippy mac nerds, then that’s fine, but don’t expect the world to change around it. As far as I’m concerned, GitHub is just a flash-in-the-pan. Remember SourceForge? Or code.google? Or the half-dozen other open-source-control systems that have come and gone? GitHub ain’t got anything special that I can see.
Tried SmartGit?
Otto,
I’ll admit I don’t use it on a daily basis, but I found Git Extensions to be a good option for Windows. It gives you explorer integration, Visual Studio integration, and command line (via MSysGit, which is a non-cygwin git environment for Windows).
Also, as far as WordPress.org goes, I’d much rather improve upon tools on our own site, instead of essentially outsourcing development to some site that frankly I don’t think is reliable. How many times has GitHub just gone completely offline in the past year and stopped a bunch of developers from getting their job done? 4? 5?
If you want to talk about building and improving tools for development and collaboration on WordPress.org, then I’m happy to join in on that conversation. But the moment you mention integrating with GitHub, then you’ve just gutted that conversation entirely.
Otto, I understand where you’re coming from but it’s pretty clear that many developers disagree with your opinion of GitHub. The opinion of many developers is that GitHub is providing better tools than WP.org *right now*, and developers are using it accordingly.
I think building better tools on WP.org is a great idea, but it doesn’t change the current tool state, or the fact that more and more WP devs are working together on GitHub in ways they weren’t able to before.
I understand that many disagree. That’s not my point. My point is that if you want to talk about improving or creating existing tools, then I’d love to help. If you want to talk about using GitHub instead of creating better tools, then I’m against that, and will adamantly argue against it, until such time as Git in general is *usable* by the majority.
You’re only seeing the results from a very small subset of developers, and frankly I’m not really interested in improving things just for “people who use GitHub”. I would rather take a wider scope, and improve things for *everybody*.
Small sample size, but using GitHub was the majority among the group of developers in the plugin discussion at #wpcs.
I’m not arguing against better tools for WP.org, I’m arguing for using better tools available now. When/if the WP.org tools improve that will be an entirely different discussion.
Yes, and something like 85-90% of them used Mac’s too. Does that mean that Mac’s are used by 85-90% of the population?
Limited sample size, skewed dataset.
If you are arguing for using tools that exist now, then that is identical to an argument against creating better ones. There is a limited amount of developer time and brainpower going into wp.org. Should we focus on making it better for a very small subset of developers, or focus on making better tools that works with a wider range of people (including non-developers) and thus creating a better way to do things overall? Pick one, we don’t have the capacity for both at once.
Also note that there are only approximately 20,000 or so developers who have ever contributed any code to WordPress.org, ever, period, in all of time and space. Plugins, themes, and core. The other 1,998,000 user accounts were not made by developers. What of them? Should we be shunting them to your GitHub bug tracking system, or making a decent bug tracking system on .org? Should we outsource the support forums too?
Every time I hear somebody say we should use GitHub, what I really hear is that they don’t want to use WordPress.org, nor are they interested in improving it. So the sub-context I see to your post really is: “I’m not interested in making things better, I just want to use what I know.” And that’s really a shame.
Point out improvements: yes.
Point out places to fix things: yes.
Point out other sites and say we should use them instead: no.
They did include some of the more active plugin developers in the community.
I completely reject this premise. I am quite capable of using existing tools while working to build new/better ones. I do this everyday.
I don’t think they are likely to submit pull requests or contribute patches.
Unrelated issues do not strengthen your argument.
I certainly can’t control what you hear, but that’s not what I’m saying. I’ve been using SVN with WordPress since 2003 and started using GitHub actively just a few years back. I learned how to use GitHub because of the benefits it offers. That doesn’t have any bearing on my feeling towards better WP.org tools.
Also note that other improvements for .org that were discussed are far more important, IMO, and will make this sort of argument somewhat futile in the medium-long run.
For example, it’s being discussed how to make more of the WordPress.org website itself open-source. As this happens, then there will be the ability for more people to contribute changes to WordPress.org, instead of having basically 3-5 people capable of working on the code. In which case, maybe you can argue your changes to support that sort of thing there, and others can help out with improving other things, same as with core.
Naturally, open-sourcing .org’s code is a big job, and will take some time to check for security issues, hide passwords, things of that nature. A fair amount of this work will lead to improvements in .org’s code even before other contributors start rolling in. It’s a game-changing idea, honestly. So in the long-run, we won’t have this argument on your blog, we’ll have it on a dotorg trac. 🙂
First of all, thanks — I was excited to get my first pull-request! It was something I had planned to do eventually, anyways (in one form or another — still thinking about changing from background-images in CSS to actual img tags, and making the icon directory a filterable option).
The documents-shortcode plugin is the first WordPress plugin I’ve hosted on GitHub (dual-hosted in the WP svn repo via git-svn). And other than the initial commit, this was the first time I had revisited the process of updating it in both git and svn. And let me tell you, the experience is not pretty. A couple of the steps doing the git/svn updates were slooooow. I think in the future, I’ll just use git on its own, and export changes to a separate svn checkout. I need to see what I can do to make that sort of process more automated and less prone to errors.
@otto: I can see where you’re coming from. If the git toolchain for Windows sucks, that’s leaving a lot of people to swing in the wind. I hope it improves soon. Obviously, moving any “official” hosting of WP assets to GitHub is unlikely anytime in the foreseeable future. But I hope that the idea of a supported plugin header for an alternate repo location is something that can be worked out.
I do have to say that receiving a pull request, being able to very easily review the patch, and accept it, is a pleasant experience. As opposed to receiving an email, with a patch attached, having to export the patch, and apply the patch manually, as I’ve done in the past with svn.
The team at my day-job has recently gone through the switch from svn to git. There were some bumps early on, but now that I have a better handle on branching and merging in git, it’s great. In svn, I always feared branching and merging.
Dougal: Most of the guidelines I’ve seen for doing git->svn involve, basically, pushing every git change to SVN, when that’s totally not necessary for our system. What you really only need to do is to push the latest version to SVN. The plugins SVN doesn’t need every little change you made in git, just the latest version. Which is why a rebase and squash is your friend.
http://stackoverflow[...]-svn-dcommit
Dougal, I’ve done this two ways:
1. Have both .svn and .git folders in your local copy and commit to both places. Aaron Campbell said he does this as well. I only commit to WP.org for releases (GitHub gets all commits).
2. Use a file merge tool to sync your local Git copy to your local SVN checkout, then commit to SVN. I do this more frequently and find the review step useful as part of packaging.
I haven’t tried this yet, but several folks have been working on the “automation” piece. Here’s my fork of Dan Cameron’s script.
*I* can’t submit pull-requests or contribute patches to your code, right now. You’re already limiting your audience, in a greater amount than I believe you realize.
Clearly it does, because as you state in the post: “I think it makes sense for the plugin and theme repositories on WordPress.org to adopt a “GitHub URL” meta property for projects.”
I don’t think that makes sense, and I think that that takes time/energy/effort away from improving and creating something better. That’s the line I really take issue with. You want .org to support a third-party service for doing development work. You want to outsource that part of our system to them. That’s a big job, and I’d rather spend energy on keeping things on .org instead of putting them onto some untrustworthy service that I can’t even reasonably use within my own development environment.
I disagree. If a dev feels he can work more efficiently using by personally using one tool over another, then it frees up more time than using something that he finds less efficient. That time could then be used towards making the other tool better.
Personally, I find .org’s tools for managing support for my plugins a bit frustrating. It was only (relatively) recently that we got email notifications for support threads, and I had given up on RSS a long time ago. So there were support questions sitting there, unanswered for ages, because I didn’t know they existed. Does that mean I want to scrap everything that’s there and move it all to GitHub? No. I love the idea of improving the .org dev/support toolchain. And I’m perfectly willing to use both .org’s tools and GitHub (or whatever) for my own convenience, until such improvements can be made.
I didn’t get the impression that this is what Alex was suggesting. Is there some harm in just having supported metadata for a URL that points to the author’s preferred support venue? I don’t think this would have to preclude use of .org.
But it invariably does. The existence of this post at all simply proves that. He doesn’t like the tools on .org, so he wants us to make it so he doesn’t have to use them at all. First it’s for the code repository, but pretty soon it’s for support forums, bug tracking, everything else.
See, I think you’re both operating under the assumption that wp.org is there for developers, to make things better for them. That’s frequently not the case. WordPress.org is focused on the users, to make things better for them. Getting a theme in is quite hard. Getting a plugin in is easier, but slowly getting harder as we start rejecting more bad things.
We have control over the content on .org. If a plugin author does bad things, we remove the plugin. In extreme cases, we patch it for them. We can fix it, we can control it, we can protect the users.
If we outsource that, in any respect, we lose that control. Ask Mika about the state of plugins trying to do bad things on .org, and that’s within a system that they know we have full control over. The moment we start pulling code in from a third party and giving control over that to anybody else, we make the job of monitoring and scanning that code 100x more difficult. It’s already too hard of a job, trying to scale it to monitoring the whole of the net is unfeasible.
So right now it’s a meta-link to point somebody elsewhere. Pretty soon, you’ll ask that we pull the code from there too, instead of having it in the SVN. Eventually you’ll say “why can’t I use my own support forums”? It’s the first pebble that starts the avalanche, and I’m going to fight to keep that mountain stable as long as I can.
If you want to have your code on WordPress.org, then I say you should have to be all-in or not. Develop any way you please, but we’re keeping the support forums, the reviews, the code, and eventually the bug tracking. I won’t let it become opt-out for any of those if I can help it, because that way lies madness.
I think that WP.org benefits by making it easy for potential contributors to get to places where active development is happening. That isn’t just WP.org anymore. Disagreement with that doesn’t change it.
And you saying it doesn’t make it true either. Again, I state that your dataset and perception of the developer set is skewed. I would argue that there are many developers you simply don’t know about.
All the people at the summit were great coders, or great writers, or very well-known and respected in the community. There is a large set of people who do much wp work that were not represented in terms of that subset. While the skill level was very high, it was a tight knit group that mostly knew of each other and communicates with each other frequently. The range f differentiation amongst them was therefore low, in terms of skill-set and tool-usage.
In other words, you’re only looking at the top 0.1% of skilled people and thinking that that is a meaningful representative of the whole. New coders need love too. Even bad coders need love too, so that they can become better coders. Saying “all the best coders I’ve seen use git” isn’t remotely close to “everybody uses git”. We need to make .org useful to the bottom 99% too.
I think we’re done here. You’re intent on arguing with things I’m not saying, so this is going nowhere.
Maybe wordpress.org should give the possibility to use git? http://gitlabhq.com/ is an MIT licensed version of github. Most people who are used to github hate working with svn. And if enough people on windows use git, good tools will appear.
Collaborative WordPress Development on GitHub (via @alexkingorg) http://t.co/q1RByqHH
Matches my thoughts exactly -> “@alexkingorg: Collaborative WordPress Development on GitHub http://t.co/dXro69VB /cc @themitcho @dougal”
@alexkingorg @themitcho @dougal Perhaps not “GitHub URL”, but “Development URL”? More service agnostic (less likely to make Mitcho cry).
@simonwheatley Sure – it’s not a specific service that matters. It’s having WP.org let devs find ways to collaborate together.
@alexkingorg I agree (and thanks for keeping the conversation going).
@simonwheatley @alexkingorg @dougal guys, guys, I’m not anti-GitHub… just don’t like duplicating codebases and histories.
Collaborative WordPress Development on GitHub : http://t.co/U8mjKSaC http://t.co/U7LZMTzO via @alexkingorg #wordpress #git #github
GitHub and WordPress plugin development: http://t.co/cm2k5s8Y
@sogrady @alexking that dude Otto… @cote should read the thread too. Classic stuff. You are so obviously right even Big Software gets it
@monkchips @alexking @cote: hilariously, @alexkingorg and i were discussing that issue in an email thread just this week
@alexkingorg – Great post, and I completely agree. Here’s a great blog that has lots of posts about why GitHub is where today’s and future’s development will happen:
http://apievangelist[...]h_Tag=GitHub
And here’s a comment on a trac ticket where I had proposed GitHub for libraries/library-type plugins and would love if it you could add your two cents to that ticket:
http://core.trac.wor[...]6#comment:43
P.S. Frankly I would prefer Mercurial and thus BitBucket because Hg commands makes so much more sense to me than Git’s but I’m resigned to the fact GitHub has won the war for being the place where developers collaborate and that’s really what it’s all about anyway. Too bad @otto42 is so against it given his role of managing functionality on wordpress.org.
Alex, I couldn’t agree more! I love the collaboration that Git allows, and have even moved to updating some plugins directly from their Git repos using a “Git URI:” in plugin headers.
It’s in an adaptation of jkudish’s updater, but enables updates for all plugins with a Git address, whether it’s on GitHub or a even a generic Git repo with Gitweb.
See https://github.com/pdclark/WordPress-GitHub-Plugin-Updater/tree/f/gitweb
http://t.co/OsyhxCPM http://t.co/vd8ZKKF1
There’s an on-going discussion on WordPress.org’s Ideas section related to this:
http://wordpress.org[...]s-and-themes
Collaborative WordPress Development on GitHub http://t.co/FUrGWNbpTm