Hello everyone,

TL;DR summary: Due to traffic exploding, we will split the current openstack list into user / usage topics (openstack list) and development / next-version topics (openstack-dev list).

Long version:

At the "Communication" session at the design summit [1] we looked at the state of our communication media in general, and mailing-list in particular [2].

[1] http://folsomdesignsummit2012.sched.org/event/366accca0fda271fc23e82b9cb5162cc [2] http://etherpad.openstack.org/FolsomCommunication

The traffic on the open...@lists.launchpad.net list doubled in the last 4 months [3], with more users and deployers asking for information on OpenStack projects. It becomes difficult for contributors to properly prioritize their ML reading, and we can no longer have all the discussions in the same place.

[3] http://openstack.markmail.org/

The proposal is to split between:

1/ Usage, deployment, Essex / current-stable discussions 2/ Development, contribution, Folsom / forward-looking discussions

A new list will be created for (2) and existing contributors will be asked to subscribe to that new list.

Since we expect to have a more disciplined/focused group in that new list, we'll define a set of subject prefixes that should be used for easier client-side/at-a-glance filtering of discussions:

[General] Affects all projects [Swift] [Nova] [Glance] [Quantum] [Horizon] [Keystone] Project-specific [Common] openstack-common [QA] [CI] [Docs] Discussions / Information on specific topics [...] Add your own here

To keep that list usable, I suggest we aggressively enforce those topics and redirect inappropriate discussions to the other list when necessary.

To avoid Launchpad list slowness, we would run the new openstack-dev list off lists.openstack.org. Given the potential hassle of dealing with spam and delivery issues on mission-critical MLs, we are looking into the possibility of outsourcing the maintenance of lists.openstack.org to a group with established expertise running mailman instances. Please let us know ASAP if you could offer such services. We are not married to mailman either -- if an alternative service offers good performance and better integration (like OpenID-based subscription to integrate with our SSO), we would definitely consider it.

There was a suggestion during the session of using umbrella/siblings lists to aggregate content from multiple project-specific sublists. I reviewed the options and I think it introduces a lot of complexity, reduces flexibility in adding new topics, so client-side filtering sounds like a better bet. If most people use subject prefixes appropriately, keeping it simple is probably the best bet.

We'll let you know when the new list is set up.

Regards,