incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Proposal: ooo-announce list
Date Sun, 11 Dec 2011 19:08:08 GMT
On Sun, Dec 11, 2011 at 1:53 PM, TJ Frazier <> wrote:
> +1 in general; quibbles in-line.
> On 12/11/2011 13:20, Rob Weir wrote:
>> I see that many other projects have an official announce list.  This
>> would be used for official public communications:
>> 1) New releases
>> 2) New services
>> 3) New blog posts
> Unnecessary. Interested parties will track these themselves.
>> 4) Security patches
> Redundant. We should have a release ready with the fix, which will be
> announced. --/tj/

Even with a release, we still should have a security announcement.

See step 14 here:

"The project team announces the release and the vulnerability.
Typically this will be sent to the reporter, the project's users list,
the project's dev list, the project's announce list,, and The project's security pages should also be
updated. This is the first point that any information regarding the
vulnerability is made public."

So there is a summary of the vulnerability that gets posted to the
announce list, and several other lists, with a CVE number (Common
Vulnerabilities and Exposures).  This makes it easy to cross reference
exactly what security issues are patches in a given release.  Maybe
not so interesting for end users to have that detail broken out, but
it is important, for example, for those who repackage and redistribute
OpenOffice, e.g., Linux distros.

We might also be coordinating with other products or components on the
announcement.  Say, hypothetically, that there is a horrible security
flaw in Hunspell.  We'd coordinate with Hunspell, and with LO and
Firefox on a patch.  We'd patch our tree and release a new AOO with
the fix.  But we would coordinate the timing of the security
announcement until LO and Firefox also had their releases ready.  You
don't want the first product that is released to "spill the beans" and
make the user's of the products that use the component vulnerable to a
now public issue.  So there might be an interval between the release
announcement and the security announcement.

Note:  this would be the exception to the rule that announcements are
pre-discussed by the PPMC.  I'd expect that such announcements would
come directly from the security team.  So we would need to have one of
the moderators for the announce list be from that team.

>> 5) Expected downtime
>> 6) Migration updates
>> The idea would be for it to be low-volume but with high membership.
>> If possible via ezmlm, it would be a read-only list except for
>> moderators.  Content for posting would first be discussed and approved
>> on ooo-dev before going out on the announce list.
>> Some might say that we could just do this via existing ooo-dev or
>> ooo-user lists, but the higher traffic on those lists is too much for
>> someone who wants only the most important notices.
>> If we do have an optional registration screen in the 3.4 install,
>> maybe this is the list we offer to sign users up for.
>> If there are no objections to this list, I'll need a few things:
>> 1) Verification that such a read-only list is possible
>> 2) A few moderator volunteers -- noting that the moderator role in
>> this case is more of an assist to help publish PPMC-approved content
>> to the list.
>> -Rob

View raw message