openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #10747
Re: Mailing-list split
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.
Comments? Feedback?
Everett
On Fri, Apr 27, 2012 at 4:04 AM, Thierry Carrez <thierry@xxxxxxxxxxxxx>wrote:
> 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
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
Follow ups
References