openstack team mailing list archive

[Thierry Carrez <thierry@xxxxxxxxxxxxx>]

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 openstack@xxxxxxxxxxxxxxxxxxx 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,

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack