incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <>
Subject Re: Extraordinary OpenOffice security patch (Was: [Incubator Wiki] Update of "April2012" by robweir)
Date Thu, 12 Apr 2012 18:50:56 GMT
On 4/12/2012 9:05 AM, Rob Weir wrote:
> On Thu, Apr 12, 2012 at 9:07 AM, Jukka Zitting <> wrote:
>> Anyway, it sounds like the case was handled reasonably well under some
>> fairly challenging constraints, so I'm not too worried about  details
>> like this as long as this remains a one-off special case. I only
>> wanted to bring this up to make sure this doesn't become a standard
>> procedure without a broader discussion of how cases like this should
>> be handled.
> If there is anything worth additional consideration, it would be how
> to handle large incubation projects, where the time to initial Apache
> release is long enough that there is a possibility or even likelihood
> of needing to release a security patch for a legacy version of the
> product.  In some cases the original sponsors of the project are still
> around and can continue to do this kind of maintenance. In other
> cases, as with OpenOffice, this is not true.
> I'd recommend that future podlings, and the IPMC, consider this aspect
> when reviewing new podling applications.  It should probably be
> treated explicitly in the wiki proposal for podlings that expect to
> take more than 3 or 4 months to get to their first release.

It has been an issue for you, and for Subversion.  Perhaps a short powwow
is in order and come up with a 'template' for the incubation proposal to
address this.

In the case of subversion, Subversion Corp didn't cease the day the project
started at the ASF. could still put out fixes.  I would
expect the same of the current proposal by Citrix, that they wouldn't need
to rely on the incubator for an interim patch.

Where this is unusual is that Oracle did in fact wash their hands on day
one, and the IPMC podling became entirely responsible for maintenance of
binaries they did not publish.  That was the mistake here, IMHO, if there
is any mistake.

The ASF can only assume responsibility for software that the ASF has,
themselves, published.  We should avoid such additional obligations the
next time we accept the incubations of preexisting works such as this.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message