Open Stack

Another thing that I remember from talking with people who work at yahoo
on the hadoop project and was an insight early on for me. I remember those
folks saying that about 2 hours of there day is spent on catching up on
mailing list emails and reviews. This is/was a change in how they operated
when they joined the hadoop (or related hadoop project) and my guess is
that this same change is happening to people in the openstack project (and
it does take some getting used to).

I also agree with the sentiment that clint has stated, where I honestly
agree that the 'chaos' is actually beneficial for a new project like
openstack (newish I guess). Without that 'chaos' I do agree that we would
not have as much innovation or cross-pollination among projects, which to
me means that we start going down a path of silos (which is bad, and
believe me at yahoo I know all about silos).

TLDR: opensource projects take some getting used to, especially with
regards to emails and reviews, but IMHO lets keep the chaos until
openstack is more mature (if that ever occurs?).

On 11/15/13 9:51 AM, "Clint Byrum" <clint at fewbar.com> wrote:

>Excerpts from Stefano Maffulli's message of 2013-11-15 09:12:05 -0800:
>> On 11/15/2013 02:06 AM, Thierry Carrez wrote:
>> > Arguments in favor of splitting openstack-dev / stackforge-dev
>> > * People can easily filter out all non-openstack discussions
>> > * Traffic would drop by about 25%
>> 
>> I'm not so convinced about this figure, as others pointed out.
>> 
>> > * Removes confusion as to which projects are actually "in openstack"
>> > 
>> > Arguments in favor of keeping it the same
>> > * Provides a cross-pollination forum where external projects can learn
>> > * More chaos creates more innovation
>> 
>> chaos creates just chaos in this context :) I don't buy Clint's rhetoric
>> applied to this case :)
>> 
>
>You say that like chaos is all bad. The trade-off is that the chaos
>create's chain reactions often leading to _more_ energy being released.
>This is not always the most efficient use of energy, but it does unlock
>energy that may never have been realized. I have to wonder if Mistral
>would have been created the way it was if TaskFlow discussions were
>divided between the "core" list and stackforge list.
>
>I think this is rather interesting, that we are debating how to scale a
>list of "compute" nodes that we call developers by effectively creating
>"cells". We all know that this only solves one problem and now creates
>another one. One cell can still be overloaded. The balance between the
>two is simply not going to hold true.
>
>Perhaps the answer is instead to look at why the compute nodes feel that
>they need to look at every single broadcast topic. Are we all using
>horrible email clients (probably, because all email clients are
>horrible) or are we just inept? Could we benefit from some training on
>this subject? Better tools? A cultural acceptance that some people will
>likely miss some messages?
>
>> Anyway, I've looked at my folder and it looks like 90% of the messages
>> to openstack-dev have topics in the subject line. Filtering on the
>> client side should be easy to do and I'd like to have a few volunteers
>> run an experiment over one week to see if filters can ease the pain.
>>
>
>I don't filter at all. I use sup-mail, which is an unmaintained ruby
>based client like notmuch that has one benefit worth using an unmaintained
>ruby anything. It very easily allows "killing" threads without deleting
>them. This means that as soon as I see a subject line is not interesting,
>I press & on the thread, and it is gone from my view. Until I do a local
>search with '\', which then searches the local xapian index and may show
>killed threads. Neat huh?  This may be why I don't favor splitting,
>because I don't get overwhelmed by long threads.. they're gone 1 or 2
>messages in.
>
>I'm not suggesting that everybody switch to sup. But rather that we try
>to investigate why the list is overwhelming people before we just split
>it in two, which I do believe will have large unintended and difficult
>to detect consequences.
>
>> I'd also like to get to an agreement that support requests sent to
>> openstack-dev should not be answered and instead should be redirected
>> gently to openstack at lists. and/or ask.openstack.org.
>> 
>
>My general sense is that this is already happening.
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev