|Thierry Carrez||Apr 27, 2012 3:04 am|
|Daniel P. Berrange||Apr 27, 2012 3:46 am|
|Jim Meyering||Apr 27, 2012 4:11 am|
|Monty Taylor||Apr 27, 2012 5:41 am|
|Monty Taylor||Apr 27, 2012 5:46 am|
|Duncan McGreggor||Apr 27, 2012 6:44 am|
|Monty Taylor||Apr 27, 2012 8:26 am|
|Duncan McGreggor||Apr 27, 2012 8:31 am|
|Stefano Maffulli||Apr 27, 2012 9:33 am|
|Everett Toews||Apr 27, 2012 12:52 pm|
|Matt Joyce||Apr 27, 2012 2:33 pm|
|Duncan McGreggor||Apr 27, 2012 2:42 pm|
|Stefano Maffulli||Apr 27, 2012 5:59 pm|
|Jim Meyering||Apr 28, 2012 2:45 pm|
|Everett Toews||Apr 30, 2012 9:12 am|
|Stefano Maffulli||Apr 30, 2012 10:08 am|
|Everett Toews||Apr 30, 2012 11:00 am|
|Duncan McGreggor||Apr 30, 2012 11:06 am|
|Matt Ray||Apr 30, 2012 11:37 am|
|Jan van Eldik||May 1, 2012 1:13 pm|
|Duncan McGreggor||May 11, 2012 1:12 pm|
|Duncan McGreggor||May 11, 2012 1:20 pm|
|Duncan McGreggor||May 17, 2012 8:40 am|
|Duncan McGreggor||May 17, 2012 8:46 am|
|Subject:||Re: [Openstack] Mailing-list split|
|From:||Matt Joyce (ma...@nycresistor.com)|
|Date:||Apr 27, 2012 2:33:01 pm|
Makes sense to me. On Apr 27, 2012 2:27 PM, "Everett Toews" <ever...@cybera.ca> wrote:
I like this idea but what happens to the openstack-operators list in this scenario?
I don't think we'd want to have the openstack and openstack-operators list going along in parallel since it sounds like they would overlap. I propose that the members of the openstack-operators list would be (automatically or manually) migrated to the openstack list. Then the openstack-operators list would be set to read-only or maybe even removed completely to avoid confusion.
On Fri, Apr 27, 2012 at 4:04 AM, Thierry Carrez <thie...@openstack.org>wrote:
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).
At the "Communication" session at the design summit  we looked at the state of our communication media in general, and mailing-list in particular .
The traffic on the open...@lists.launchpad.net list doubled in the last 4 months , 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.
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.
-- Thierry Carrez (ttx) Release Manager, OpenStack