openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus <>
Subject Re: Planning for emergency releases
Date Sun, 07 Aug 2016 15:09:45 GMT
Am 08/06/2016 02:41 AM, schrieb Dennis E. Hamilton:
>> -----Original Message-----
>> From: Marcus []
>> Sent: Friday, August 5, 2016 14:21
>> To:
>> Subject: Re: Planning for emergency releases
>> Am 08/05/2016 10:43 PM, schrieb Patricia Shanahan:
>>> This is mainly a summary of opinions I've already expressed on
>>> security@. The discussion does not actually involve anything that
>> needs
>>> to be confidential, so it should be taking place on dev@ instead.
>>> This is controversial - I expect replies disagreeing with my views.
>> The
>>> point of this thread is to hash out the diverging opinions and reach a
>>> consensus:
>>> [...]
>> I don't expect many of this kind of issues. Nevertheless, I don't want
>> to install everytime a complete new release for a fix that is related to
>> 1% (?) of the AOO installation. For me it would be like taking a
>> sledgehammer to crack a nut.
> [orcmid]
> Marcus.  I am not certain what you mean by 1% of AOO installations?

I meant the affected part in an AOO installation. So, the fix affects 
only 1%. Of course assumed you have installed Impress and/or using it 
with presentation files.

>> Furthermore, what needs to be done on our side:
>> - more testing if the application is still working when we build every
>>     byte new from scratch.
>> - upload the files of hundreads of megabytes to SourceForge
>> - the connected mirrors need to sync them all
>> - earliest after x days the new release is distributed and the downlod
>>     is actually working
>> - agreement how to increase the version number. Everytime x.y.z+1 just
>>     for a little fix?
>> I hate this comparison but OK. Microsoft has a similar big office suite.
>> But I've never seen a new release with just a fix. They always provide
>> (more or less) little patch files. Sure, they will be searched,
>> downloaded and installed automtically, so the user doesn't need to do
>> much. But still, they are little files.
> [orcmid]
> I agree that we do need to understand the friction that our build and deployment process
raises.  But improving that will take longer.  It is valuable to do for many reasons, but
it means revamping our build and distribution process in major ways, especially for our Windows
> We need a manageable process for when we are under a strict time window because a vulnerability
will become known or, worse, there is an active exploit "in the wild."  Perhaps it means addressing
only one or two platforms, limiting the number of localizations addressed, or other shortcuts.
> I do believe that if we are talking about maintenance releases of an existing, stable
release, the QA process can be limited to confirming that there is no regression.

right, best conditions to provide one or more patched files.


>> Or compare it with a car: You have a little scratch in your paint. Do
>> you really request a new paint for the complete car in the painter
>> garage?
>> So, for me this sounds not smart. ;-)
>> Better would be really to deliver selected patched files.
>> Sure for this we need to:
>> - straighten the build process
>> - provide a smarter install routine than just a detailed readme text
>> - create new separate download webpages for the fixes with different
>>     content - at least for the describing text

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

View raw message