We’ve moved the SVN and Trac firehose mailing…

We’ve moved the SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. and TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. firehose mailing lists to lists.wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/, from the legacy lists.automattic.com. If all goes well, we’ll move the rest of them over as well.

The one side effect is this is likely to break your existing mail filters. The new mailing list emails are wp-trac@lists.wordpress.org and wp-svn@lists.wordpress.org. If you’re using Gmail’s mailing list filters, those would now look like list:wp-trac.lists.wordpress.org.

For those of you who use Gmail, I’ve also added basic styling to the SVN commit emails. Hooray for reading diffs with red and green. (For those who don’t use Gmail, you’ve already been seeing styling that Gmail strips out.)

Just a reminder you don’t *need* to use the Trac firehose. You can also subscribe to individual tickets, milestones, components, focuses, new tickets, etc.

Another note: WordPress.org is now forced SSLSSL Secure Sockets Layer. Provides a secure means of sending data over the internet. Used for authenticated and private actions.. Announcement and details here.

gmail-diffs

#mailing-lists, #notifications, #svn, #trac

For those of you who receive wp svn…

For those of you who receive wp-svn commit emails: I’m considering a simple change to reduce some of the noise on that list. The change would be to not email any commits by bumpbot or potbot.

One of the original goals of bumpbot was to reduce the noise when doing code review on a commit that involved JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. or CSSCSS Cascading Style Sheets.. But these commits can occur fairly often and still cause noise.

The concern is two-fold:

  1. Will skipped commit numbers cause people to look around for them, so instead of saving time, it actually increases time spent on these?
  2. If a bot screws up and no one is around to hear it, does it makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). a sound?

I think #1 is surmountable. #2 can be solved in a few ways. One, the commits will still be posted to IRCIRC Internet Relay Chat, a network where users can have conversations online. IRC channels are used widely by open source projects, and by WordPress. The primary WordPress channels are #wordpress and #wordpress-dev, on irc.freenode.net. by svn-bot, and viewable in TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.’s timeline. Two, we could continue to have them sent to a few people, if necessary. Also, these bots have made few mistakes over the years, as every time there’s been a bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority., we’ve fixed it. Of course, it’s all just VCS, so any issue can be reverted. And we have protection in place around releases to make sure the bots did their jobs and “run clean”.

Anyone have a strong opinion either way?

#bots, #mailing-lists, #svn, #wp-svn