<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 16-09-20 05:38 PM, Morgan Fainberg
wrote:<br>
</div>
<blockquote
cite="mid:CAGnj6atmmmv-EPGKcuZVJTyHeyLDhMvV5J_KaGWc+3BiMYZA3Q@mail.gmail.com"
type="cite">
<pre wrap="">On Tue, Sep 20, 2016 at 9:18 AM, Doug Hellmann <a class="moz-txt-link-rfc2396E" href="mailto:doug@doughellmann.com"><doug@doughellmann.com></a>
wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Excerpts from Thierry Carrez's message of 2016-09-20 10:19:04 +0200:
</pre>
<blockquote type="cite">
<pre wrap="">Steve Martinelli wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I think bundling the puppet, ansible and oslo releases together would
cut down on a considerable amount of traffic. Bundling or grouping new
releases may not be the most accurate, but if it encourages the right
folks to read the content instead of brushing it off, I think thats
worth while.
</pre>
</blockquote>
<pre wrap="">
Yeah, I agree that the current "style" of announcing actively trains
people to ignore announces. The trick is that it's non-trivial to
regroup announces (as they are automatically sent as a post-job for each
tag).
Solutions include:
* A daily job that catches releases of the day and batches them into a
single announce (issue being you don't get notified as soon as the
release is available, and the announce email ends up being extremely
</pre>
</blockquote>
<pre wrap="">long)
</pre>
<blockquote type="cite">
<pre wrap="">
* A specific -release ML where all announces are posted, with a daily
job to generate an email (one to -announce for services, one to -dev for
libraries) that links to them, without expanding (issue being you don't
have the natural thread in -dev to react to a broken oslo release)
* Somehow generate the email from the openstack/release request rather
than from the tags
</pre>
</blockquote>
<pre wrap="">
One email, with less detail, generated when a file merges into
openstack/release is my preference because it's easier to implement.
Alternately we could move all of the announcements we have now to
a new -release list and folks that only want one email a day can
subscribe using digest delivery. Of course they could do that with
the list we have now, too.
Doug
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<pre wrap="">
A release list makes a lot of sense. If you also include clear metadata in
the subject such as including the owning project aka: keystone (for
keystone auth, keystonemiddleware, keystoneclient), people can do direct
filtering for what they care about ( as well digest mode).
--/morgan
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
Also you can set the description for the list to state the fact this
list is meant for releases, so it will curtail complaints from
subscribers saying we don't like what we are getting.<br>
<br>
Thanks,<br>
Anita.<br>
</body>
</html>