← Back to team overview

openstack team mailing list archive

Development ML (was: creating a mailinglist for packaging specific topics?)

 

Jay Pipes wrote:
> So, the topic of multiple mailing lists has come up before and we've
> even tried topical mailing lists before, but the amount of traffic on
> them tends to be too low for it to be worth the extra ML subscription.
> I've also made the argument before that with a general mailing list
> (this one), you get a wider audience and people that may not always get
> excited about distribution specifics may be exposed to important
> discussions, learn something new, and in general just be made aware of
> the state of a particular subcommunity by scanning/skimming emails.

I agree that topical development MLs are not worth it...

That said, I think it's time to split development discussions from
user/operations questions. Over the recent months with more people using
OpenStack the volume of non-development-related emails has reached a
level that makes it difficult to parse. As an example, I read all the
development emails, while I only read the rest of the emails based on
topic -- separating the lists would be a great help for me. The
audiences are slightly different too.

The risks are that (1) non-development topics end up in the development
mailing-list anyway, and (2) developers ignore the non-development ML.
In order to mitigate those risks, I propose that we create a new
openstack-dev mailing-list, only for development discussions (new deps,
blueprint discussion, FFEs, packaging, core-dev proposals...).
Everything else should remain on the usual list, including governance
discussions, usage discussions, community events etc.

Creating a new list should avoid most of risk (1), and we should just be
careful to redirect non-development-related topics to the other ML if it
still happens. Developers should still be subscribed to the usual ML to
catch up with all the other openstack topics, which should avoid most of
risk (2).

What do you think ?

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack


Follow ups

References