On Sun, Dec 11, 2011 at 1:53 PM, TJ Frazier <[email protected]> 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, [email protected], [email protected] and [email protected]. The project's security pages should also be updated. This is the first point that any information regarding the vulnerability is made public." http://www.apache.org/security/committers.html 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 >> >> > >
