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 <thie...@openstack.org>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@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, > > -- > Thierry Carrez (ttx) > Release Manager, OpenStack > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
