On 8/5/2016 2:20 PM, Marcus wrote:
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.
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.
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
My 2 ct.
If we actually had a smooth, automatic patch facility I would, of
course, prefer using that to redistributing the complete binaries.
I don't agree with the car analogy - bits are relatively cheap, and I
will personally promise to recycle any obsoleted bits that are returned
to us, without taking up any landfill space. I would not do that for a
car recall.
If we had the resources of the Microsoft Office team, I would agree with
assigning half a dozen programmers per platform to produce a smooth,
user-friendly, upgrade process.
To me, having a process we can do reasonably quickly, that real end
users can apply is essential. Making that work with small downloads
would be nice to have. Is it so important that we want to spend the
resources to do it?
This is a situation in which the perfect is the enemy of the good. If we
wait to rehearse an emergency fix until after we have a usable patch
facility, we will be caught unprepared if an emergency happens.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
