http://www.evanmiller.org/rank-hotness-with-newtons-law-of-cooling.html

Ranking simply by number of votes doesn't work well when we don't actively clean out outdated items. By baking in an aging mechanism, we can help surface more recent items which get activity around them.

add an *option* to automatically sync individual WordPress.org SVN repos w/ an external Git repo (at Github, or anywhere else).

Ah. It's very unlikely to be an external source. WP would have to spin their own up (since if you've noticed, there isn't much offloading of anything, especially services). And at that point, why would we have TWO places? That's more work for everyone.

There were a lot of rumblings about this on Twitter last night, so maybe the folks behind the curtain will come up with a lengthy explanation.

What Matt tweeted last night:

There are no panaceas in development, would love to see the Git vs. SVN conversation shift to action improving the plugin/theme directory.

And “abandon it and force everyone to a third-party service” is not an answer I’m comfortable with. :)

Like: intercept commits from non-authorized users and translate to public one-click applicable patch queue on plugin dev page.

With automatic props, plugin page recognition, and profile page recognition, natch.

Finally: in the meantime, any SCM option will need to be fully two-way, using something like http://subgit.com/ - have best of both worlds

Login-integration won't be a big problem as most git server uses SSH-keys.

We will need to add some extra custom fields so user can manage their public-keys from web-based front-end.

Unless, we plan to create something fancy like Github, we can use gitolite in backend for access-control, a simple web-based git viewer (for read-only surfing)

Biggest challenge will be to move current trac-svn binding to trac-git (http://trac.edgewall.org/wiki/TracGit)

I thought about few things already. Lets take example of theme-reviews.

1. We can use git's branching concept.
2. Stable branch will always point to latest-tag (a convention)
3. Only admin can "move" stable branch
4. A developer will play along 'master' (equivalent to svn trunk) and when his changes will be ready, will use git tag but he wont be able to update stable branch
5. Admin (theme-review team) can check latest tag (diff may be) to decide if new tag should be approved (approval mean moving stable branch)

At many places, git hooks will come to rescue. A hook will update http://wordpress.org/extend/themes/ whenever stable branch is updated.
A hook will notify theme review team (or create a trac ticket) whenever new tag is pushed and things like that.

I acknowledge this is much bigger problem to solve but I think if *someday* we gotta move to git, sooner we do it, will be better!

Right now many developers are using Git as their main VCS, and then just copying to SVN every time they make a release. All I'm saying is that we should automate that last step, instead of having to do it manually.

We use a shell-script to automate last step. Check this: https://github.com/rtCamp/wp-plugin-bootstrap/blob/master/deploy.sh

deploy.sh approach is better as you can your new git tag gets synced to SVN repo instantly.

If wordpress.org periodically scans every git repo out there, it will create huge (mostly unwanted) traffic.

IMHO, if wordpress.org decides to add something for Git-world then webhook support might be a better thing (but it may need to deal with have things like security)

I'm not saying that we should scrap everything and redo it from scratch with Git. I think we should leave everything as it is, and then add an *option* to automatically sync individual WordPress.org SVN repos w/ an external Git repo (at Github, or anywhere else).

Right now many developers are using Git as their main VCS, and then just copying to SVN every time they make a release. All I'm saying is that we should automate that last step, instead of having to do it manually.

So, the process could look something like this:

1) Add an input field on the Developers tab of /extend/plugins/[plugin-name]. Plugin admins can enter the path to a Git repo (e.g., git://github.com/iandunn/WordPress-Plugin-Skeleton.git)
2) WordPress.org will periodically scan that URL, and use svn2git to sync any changes to the .org SVN repo.
3) So, anytime a new tag is pushed to the Git repo, it automatically shows up in the SVN repo with an hour or so.

That way, developers can choose to easily switch to Git without the hassle of manually copying each release to SVN, or setting up their own automated scripts.

Also keep in mind that we integrated logins and checkins with the front end pages you see on /extend/plugins. The login you use is the same for all of .org, we have to figure that out. Forum integration. All the cool new things we have with the headers and the reviews. We don't want to lose that, so we get to rewrite it?

Plugin/theme review. Themes are integrated, plugins are not. How do we want to handle each of those? Mind you, that's a much bigger issue that just a different type of repository.

Finally? What if we don't wanna go to Git? Not everyone likes it, or finds it all that 'simple.' Are we sure Thats the right solution for plugins/themes/core? Who is going to write the documentation for the handbook so people know how to submit patches?

IMO, it's actually one of those things where it would be easier to just start over ;) and really that's not acceptable either.

I'm not saying this is a bad idea, I'm saying this is a huge project that needs more thought and attention than a forum post oft provide. Someone needs to sit down and do more than pitch an idea at this point, and lay out options and suggestions with some code examples. Images too, to show what's going on.

If you mean we have used path-based access-control for plugin-folders rather than one SVN repo per-plugin-project then that can be fixed using a simple script wrapping around - https://github.com/nirvdrum/svn2git

We have moved 100s of projects from SVN to GIT internally. svn2git is quite stable.

One issue we may face is moving git access-control details. I guess we can either parse svn-rules to gitolite (assuming wordpress.org will use gitolite on public git-server) or simply scan each plugin-repo for commits. A person who had commit in SVN repo-path, will get write-access to corresponding git repo.

If this idea ever goes ahead, I would like to contribute to it. Having worked on gitolite, svn2git projects - I think I might able to contribute my $0.02 :-)

That kind of meta field could be used in this context, to tell the WP.org repo where to fetch tags and import them into WP.org SVN.

He mentioned GitHub specifically, but there's no reason it couldn't be any publicly accessible Git repo.

http://alexking.org/blog/2012/11/06/wordpress-collaboration-github

I took a look at that and am going to give it a try, only copying my own plugin repositories.

/peter