You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Patricia Shanahan <pa...@acm.org> on 2016/08/05 20:43:44 UTC
Planning for emergency releases
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:
Although I has not yet happened, there is a risk that AOO could be the
subject of an in-the-field exploit of some, as yet unknown, security
vulnerability. If that happened, users would have to suspend using AOO
until we get a fix to them in a form they can use. If that suspension
went on too long, or any significant number of users were harmed, AOO
would be dead.
We need a plan for releasing an emergency fix, and we need to rehearse
the plan, possibly by picking a relatively minor, not yet exploited, bug
and following the emergency process for it.
The only effective way to get a fix distributed to most of the end users
is to create and upload to SourceForge a new set of binaries. My
reasoning is that anyone using AOO can either download and install
software, or has someone who can and will do it for them. There is
nothing else we can depend on. In particular, we cannot depend on the
ability to follow an unfamiliar set of instructions accurately.
Note that most Apache projects distribute software that is installed and
managed by programmers or system administrators, who are experienced in
following non-trivial instructions accurately. AOO can be installed and
managed by non-technical end users.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Marcus <ma...@wtnet.de>.
Am 08/05/2016 11:59 PM, schrieb Dave Fisher:
> Until AOO can provide a simple auto-update that includes patches then from a user perspective Patricia is completely correct.
I don't believe that this can be the only agrument to provide a
full-blown release. ;-)
Marcus
>> On Aug 5, 2016, at 2:20 PM, Marcus<ma...@wtnet.de> 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.
>>
>> Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Dave Fisher <da...@comcast.net>.
Hi Marcus,
Until AOO can provide a simple auto-update that includes patches then from a user perspective Patricia is completely correct.
Regards,
Dave
Sent from my iPhone
> On Aug 5, 2016, at 2:20 PM, Marcus <ma...@wtnet.de> 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.
>
> Marcus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Marcus <ma...@wtnet.de>.
Am 08/06/2016 02:41 AM, schrieb Dennis E. Hamilton:
>> -----Original Message-----
>> From: Marcus [mailto:marcus.mail@wtnet.de]
>> Sent: Friday, August 5, 2016 14:21
>> To: dev@openoffice.apache.org
>> 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 users.
>
> 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.
Marcus
>> 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: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Planning for emergency releases
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Marcus [mailto:marcus.mail@wtnet.de]
> Sent: Friday, August 5, 2016 14:21
> To: dev@openoffice.apache.org
> 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?
My biggest concern, with respect to potential exploits is that the obvious target is using crafted Microsoft Office files that find vulnerabilities on the Windows versions of Apache OpenOffice. That is a very large target in terms of the Apache OpenOffice community. There is also the prospect of exploits via crafted ODF files.
Please explain what you mean by the 1%.
> 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 users.
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.
>
> 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.
>
> Marcus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Marcus <ma...@wtnet.de>.
Am 08/07/2016 06:19 PM, schrieb Patricia Shanahan:
>
>
> On 8/7/2016 8:29 AM, Marcus wrote:
>> Am 08/06/2016 12:57 AM, schrieb Patricia Shanahan:
> ...
>>> 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.
>>
>> I don't understand what you meant. At the end you would repaint your
>> whole car when you have just a scratch?
> ...
>
> To make that analogy work, we have to assume that fixing a single
> scratch is far, far more complicated and expensive than repainting the car.
sorry, I still don't get it. Why assume it? To know it would be better.
But I don't expect a new answer. Let's stick to the real problem. ;-)
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Patricia Shanahan <pa...@acm.org>.
On 8/7/2016 8:29 AM, Marcus wrote:
> Am 08/06/2016 12:57 AM, schrieb Patricia Shanahan:
...
>> 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.
>
> I don't understand what you meant. At the end you would repaint your
> whole car when you have just a scratch?
...
To make that analogy work, we have to assume that fixing a single
scratch is far, far more complicated and expensive than repainting the car.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Patricia Shanahan <pa...@acm.org>.
On 8/7/2016 10:16 AM, Marcus wrote:
> Am 08/07/2016 06:14 PM, schrieb Patricia Shanahan:
...
>> but meanwhile work on getting competent at preparing a full release
>> promptly if needed.
>
> Maybe we are not that far aways from each other. What I want to to avoid
> is to provide hundreads of MBs for a single fix. Of course we can do a
> 4.1.3 with some collected fixes. As I don't know what is coming in the
> future I would not love to see another 4.1.4, 4.1.5, 4.1.6, etc. when
> the calendar is still showing 2016. ;-)
I think our basic disagreement is a priorities issue.
I don't see any value at all in conserving version numbers.
I do see a benefit to limiting download bandwidth, but to my mind that
is an utterly insignificant issue compared to the convenience of each of
a few hundred thousand relatively unskilled end users.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Marcus <ma...@wtnet.de>.
Am 08/07/2016 07:38 PM, schrieb Dennis E. Hamilton:
>
>
>> -----Original Message-----
>> From: Marcus [mailto:marcus.mail@wtnet.de]
>> Sent: Sunday, August 7, 2016 10:16
>> To: dev@openoffice.apache.org
>> Subject: Re: Planning for emergency releases
>>
>> Am 08/07/2016 06:14 PM, schrieb Patricia Shanahan:
>>>
>>> On 8/7/2016 8:29 AM, Marcus wrote:
>>> ...
>>>> I don't want to have it perfect. And we are already in this emergency
>>>> situation. We have either a patch process nor a full-release process.
>>>
>>> We don't have what I consider to be the full emergency, a live exploit
>>> in the field.
>>
>> OK, ACK.
>>
>>> Why not both strategies? Go ahead with the inferior, clumsy,
>>> user-hostile patch process because that is the best we can do this
>> week,
>>
>> I would do it (or help) when I had some knowledge in Windows batch
>> programming. Unfortunately ...
> [orcmid]
>
> That part, I can do [;<).
great, then I would like to test this.
>>> but meanwhile work on getting competent at preparing a full release
>>> promptly if needed.
>>
>> Maybe we are not that far aways from each other. What I want to to avoid
>> is to provide hundreads of MBs for a single fix. Of course we can do a
>> 4.1.3 with some collected fixes. As I don't know what is coming in the
>> future I would not love to see another 4.1.4, 4.1.5, 4.1.6, etc. when
>> the calendar is still showing 2016. ;-)
> [orcmid]
>
> So far, we have the good fortune of a fix having its effect only in a single shared library, with no problems of substitution into the already-shipped stable binary.
>
> Other problems may not be so easy.
>
> And with these fixes like 4.1.2-patch1, the level of end-user expertise required is a problem.
>
> Perhaps we will learn to do this kind of fix quickly and with less experimentation in the future. We are learning a great deal here.
Of course. When we get fixes that consists of several files that need to
be replaced, then a full release is maybe the better solution.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Planning for emergency releases
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Marcus [mailto:marcus.mail@wtnet.de]
> Sent: Sunday, August 7, 2016 10:16
> To: dev@openoffice.apache.org
> Subject: Re: Planning for emergency releases
>
> Am 08/07/2016 06:14 PM, schrieb Patricia Shanahan:
> >
> > On 8/7/2016 8:29 AM, Marcus wrote:
> > ...
> >> I don't want to have it perfect. And we are already in this emergency
> >> situation. We have either a patch process nor a full-release process.
> >
> > We don't have what I consider to be the full emergency, a live exploit
> > in the field.
>
> OK, ACK.
>
> > Why not both strategies? Go ahead with the inferior, clumsy,
> > user-hostile patch process because that is the best we can do this
> week,
>
> I would do it (or help) when I had some knowledge in Windows batch
> programming. Unfortunately ...
[orcmid]
That part, I can do [;<).
>
> > but meanwhile work on getting competent at preparing a full release
> > promptly if needed.
>
> Maybe we are not that far aways from each other. What I want to to avoid
> is to provide hundreads of MBs for a single fix. Of course we can do a
> 4.1.3 with some collected fixes. As I don't know what is coming in the
> future I would not love to see another 4.1.4, 4.1.5, 4.1.6, etc. when
> the calendar is still showing 2016. ;-)
[orcmid]
So far, we have the good fortune of a fix having its effect only in a single shared library, with no problems of substitution into the already-shipped stable binary.
Other problems may not be so easy.
And with these fixes like 4.1.2-patch1, the level of end-user expertise required is a problem.
Perhaps we will learn to do this kind of fix quickly and with less experimentation in the future. We are learning a great deal here.
>
> Marcus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Planning for emergency releases
Posted by "Dennis E. Hamilton" <de...@acm.org>.
+1 on the permanent "ready to release" mode.
> -----Original Message-----
> From: Marcus [mailto:marcus.mail@wtnet.de]
> Sent: Monday, August 8, 2016 11:15
> To: dev@openoffice.apache.org
> Subject: Re: Planning for emergency releases
>
> Am 08/08/2016 07:28 PM, schrieb Andrea Pescetti:
> > On 07/08/2016 Marcus wrote:
> >> Maybe we are not that far aways from each other. What I want to to
> avoid
> >> is to provide hundreads of MBs for a single fix. Of course we can do
> a
> >> 4.1.3 with some collected fixes. As I don't know what is coming in
> the
> >> future I would not love to see another 4.1.4, 4.1.5, 4.1.6, etc. when
> >> the calendar is still showing 2016. ;-)
> >
> > The right trade-off would be between two and three releases a year
> > (including maintenance releases).
> >
> > Based on history, we've never been -and we are not- in a "release now
> > since there is a known critical exploit circulating", so the
> "emergency
> > release" is not likely to happen often.
> >
> > It will be enough to be in a permanent "ready to release" mode (where
> > work is still mostly on the infrastructure side, the rest is OK) and
> use
> > this readiness to ship emergency releases in the unlikely case we need
> > one, and a few maintenance/feature releases from time to time.
>
> it seems we have the same wish with regard to releases. We can just hope
> that this can come true.
>
> Marcus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Planning for emergency releases
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Patricia Shanahan [mailto:pats@acm.org]
> Sent: Monday, August 8, 2016 21:26
> To: dev@openoffice.apache.org
> Subject: Re: Planning for emergency releases
>
> On 8/8/2016 11:14 AM, Marcus wrote:
> > Am 08/08/2016 07:28 PM, schrieb Andrea Pescetti:
> >> On 07/08/2016 Marcus wrote:
> >>> Maybe we are not that far aways from each other. What I want to to
> avoid
> >>> is to provide hundreads of MBs for a single fix. Of course we can do
> a
> >>> 4.1.3 with some collected fixes. As I don't know what is coming in
> the
> >>> future I would not love to see another 4.1.4, 4.1.5, 4.1.6, etc.
> when
> >>> the calendar is still showing 2016. ;-)
> >>
> >> The right trade-off would be between two and three releases a year
> >> (including maintenance releases).
> >>
> >> Based on history, we've never been -and we are not- in a "release now
> >> since there is a known critical exploit circulating", so the
> "emergency
> >> release" is not likely to happen often.
> >>
> >> It will be enough to be in a permanent "ready to release" mode (where
> >> work is still mostly on the infrastructure side, the rest is OK) and
> use
> >> this readiness to ship emergency releases in the unlikely case we
> need
> >> one, and a few maintenance/feature releases from time to time.
> >
> > it seems we have the same wish with regard to releases. We can just
> hope
> > that this can come true.
> >
>
> +1 on "ready to release" mode. However, rather than just hoping it can
> come true, I would like to work on a plan to make it come true.
[orcmid]
++1 on that [;<). Having a path to this and actionable practical steps will be great.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Planning for emergency releases
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Patricia Shanahan [mailto:pats@acm.org]
> Sent: Sunday, August 14, 2016 16:28
> To: dev@openoffice.apache.org
> Subject: Re: Planning for emergency releases
>
> On 8/12/2016 2:14 PM, Dennis E. Hamilton wrote:
> >
> >
> >> -----Original Message----- From: Patricia Shanahan
> >> [mailto:pats@acm.org]
> ...
> >> Personally, I would like to treat the last stable release as the
> >> base for emergency fixes. I started out suggesting using the
> >> current patch as an exercise to work through the process for doing
> >> that.
> >>
> >> However, I have seen a lot of push back on the idea of ever doing
> >> a release that only has one change.
> > [orcmid]
> >
> > Yes. It might be necessary to do triage - choose highly-vulnerable
> > platforms, common languages, etc.
> >
> > And, if we are talking about an unpatched vulnerability with an
> > exploit in the wild, I don't think the ASF Board will be sympathetic
> > to our reticence.
> >
> > I agree that we do need to do fire drills simply to be able to
> > respond when an emergency arises.
>
> I would prefer to see agreement within the PMC on an emergency release
> process, followed by a fire drill to test it. My understanding, from
> following board@apache.org, is that if the ASF Board ever gets involved,
> they will swing hammers not scalpels.
[orcmid]
Patricia,
I agree that this is a matter for project governance.
I suppose it is a matter of setting a policy with regard to emergency preparedness, having timely responses to serious defects (security vulnerabilities, loss-of-data crashers, corrupted operation, etc.) that deserve speedy remedies. Historically, there are ways of accomplishing this from hotfixes for those encountering the problem to updates (less than wholesale), and new releases.
I think the discussion and determination can go here on dev@. It seems like an appropriate major topic.
So, how can we deliberate on this and come to a conclusion as to direction and then execution?
- Dennis
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Patricia Shanahan <pa...@acm.org>.
On 8/12/2016 2:14 PM, Dennis E. Hamilton wrote:
>
>
>> -----Original Message----- From: Patricia Shanahan
>> [mailto:pats@acm.org]
...
>> Personally, I would like to treat the last stable release as the
>> base for emergency fixes. I started out suggesting using the
>> current patch as an exercise to work through the process for doing
>> that.
>>
>> However, I have seen a lot of push back on the idea of ever doing
>> a release that only has one change.
> [orcmid]
>
> Yes. It might be necessary to do triage - choose highly-vulnerable
> platforms, common languages, etc.
>
> And, if we are talking about an unpatched vulnerability with an
> exploit in the wild, I don't think the ASF Board will be sympathetic
> to our reticence.
>
> I agree that we do need to do fire drills simply to be able to
> respond when an emergency arises.
I would prefer to see agreement within the PMC on an emergency release
process, followed by a fire drill to test it. My understanding, from
following board@apache.org, is that if the ASF Board ever gets involved,
they will swing hammers not scalpels.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Planning for emergency releases
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Patricia Shanahan [mailto:pats@acm.org]
> Sent: Friday, August 12, 2016 13:55
> To: dev@openoffice.apache.org
> Subject: Re: Planning for emergency releases
>
>
>
> On 8/12/2016 1:40 PM, Dennis E. Hamilton wrote:
> >> -----Original Message----- From: Patricia Shanahan
> >> [mailto:pats@acm.org] Sent: Thursday, August 11, 2016 11:07 To:
> >> dev@openoffice.apache.org Subject: Re: Planning for emergency
> >> releases
> >>
> > [ ... ]
> >>
> >> Meanwhile, it is interesting for contemplating a ready-to-release
> >> strategy. We would need to pick a step at which to hold a release
> >> that minimizes the time to put in one critical fix and ship it.
> > [orcmid]
> >
> > It strikes me that an always-existing candidate for a ready to
> > release is the last-previous stable release.
> >
> > The biggest reason is that there only needs to be regression testing,
> > since it is presumably well-established that said release is stable
> > and that has been confirmed on the ground by the success of users.
> >
> > There could be something else that is close, but it strikes me that
> > would probably be a pending maintenance release that is basically
> > about bug fixes and any simple things.
> >
> > I note that, for changing the installer, something we would like to
> > do, the rebuild of a stable release at least needs to be done and
> > checked to see that the install produces the same result. If that
> > were tested to satisfaction, it would also qualify as a
> > ready-to-release base without having to be put in the wild.
>
> Personally, I would like to treat the last stable release as the base
> for emergency fixes. I started out suggesting using the current patch as
> an exercise to work through the process for doing that.
>
> However, I have seen a lot of push back on the idea of ever doing a
> release that only has one change.
[orcmid]
Yes. It might be necessary to do triage - choose highly-vulnerable platforms, common languages, etc.
And, if we are talking about an unpatched vulnerability with an exploit in the wild, I don't think the ASF Board will be sympathetic to our reticence.
I agree that we do need to do fire drills simply to be able to respond when an emergency arises.
- Dennis
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Patricia Shanahan <pa...@acm.org>.
On 8/12/2016 1:40 PM, Dennis E. Hamilton wrote:
>> -----Original Message----- From: Patricia Shanahan
>> [mailto:pats@acm.org] Sent: Thursday, August 11, 2016 11:07 To:
>> dev@openoffice.apache.org Subject: Re: Planning for emergency
>> releases
>>
> [ ... ]
>>
>> Meanwhile, it is interesting for contemplating a ready-to-release
>> strategy. We would need to pick a step at which to hold a release
>> that minimizes the time to put in one critical fix and ship it.
> [orcmid]
>
> It strikes me that an always-existing candidate for a ready to
> release is the last-previous stable release.
>
> The biggest reason is that there only needs to be regression testing,
> since it is presumably well-established that said release is stable
> and that has been confirmed on the ground by the success of users.
>
> There could be something else that is close, but it strikes me that
> would probably be a pending maintenance release that is basically
> about bug fixes and any simple things.
>
> I note that, for changing the installer, something we would like to
> do, the rebuild of a stable release at least needs to be done and
> checked to see that the install produces the same result. If that
> were tested to satisfaction, it would also qualify as a
> ready-to-release base without having to be put in the wild.
Personally, I would like to treat the last stable release as the base
for emergency fixes. I started out suggesting using the current patch as
an exercise to work through the process for doing that.
However, I have seen a lot of push back on the idea of ever doing a
release that only has one change.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Planning for emergency releases
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Patricia Shanahan [mailto:pats@acm.org]
> Sent: Thursday, August 11, 2016 11:07
> To: dev@openoffice.apache.org
> Subject: Re: Planning for emergency releases
>
[ ... ]
>
> Meanwhile, it is interesting for contemplating a ready-to-release
> strategy. We would need to pick a step at which to hold a release that
> minimizes the time to put in one critical fix and ship it.
[orcmid]
It strikes me that an always-existing candidate for a ready to release is the last-previous stable release.
The biggest reason is that there only needs to be regression testing, since it is presumably well-established that said release is stable and that has been confirmed on the ground by the success of users.
There could be something else that is close, but it strikes me that would probably be a pending maintenance release that is basically about bug fixes and any simple things.
I note that, for changing the installer, something we would like to do, the rebuild of a stable release at least needs to be done and checked to see that the install produces the same result. If that were tested to satisfaction, it would also qualify as a ready-to-release base without having to be put in the wild.
- Dennis
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Patricia Shanahan <pa...@acm.org>.
On 8/11/2016 10:45 AM, Marcus wrote:
> Am 08/10/2016 12:25 AM, schrieb Patricia Shanahan:
>> On 8/9/2016 3:12 PM, Marcus wrote:
>> ...
>>> we have a documented release process here [1]. Of course it's for a full
>>> release. But for a bugfix (or emergency) release it can be derived and
>>> then shortend.
>>>
>>> [1]
>>> https://cwiki.apache.org/confluence/display/OOOUSERS/Release+Planning+Template
>>>
>>>
>>
>> That is the documentation I found before. Looking only at the steps
>> labeled "Release Manager", I do know how to make announcements on
>> mailing lists, even if I do sometimes get into autocomplete tangles and
>> pick the wrong list, and how to run votes.
>>
>> That leaves
>>
>> [...]
>
> OK, then it's not what you have searched for. As I don't know the
> details that are missing I cannot really help more than this.
>
> Sorry
Don't be. It's a starting point. My next step is going to be to try to
fill in the details, doing step-by-step searches.
Meanwhile, it is interesting for contemplating a ready-to-release
strategy. We would need to pick a step at which to hold a release that
minimizes the time to put in one critical fix and ship it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Marcus <ma...@wtnet.de>.
Am 08/10/2016 12:25 AM, schrieb Patricia Shanahan:
> On 8/9/2016 3:12 PM, Marcus wrote:
> ...
>> we have a documented release process here [1]. Of course it's for a full
>> release. But for a bugfix (or emergency) release it can be derived and
>> then shortend.
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/OOOUSERS/Release+Planning+Template
>>
>
> That is the documentation I found before. Looking only at the steps
> labeled "Release Manager", I do know how to make announcements on
> mailing lists, even if I do sometimes get into autocomplete tangles and
> pick the wrong list, and how to run votes.
>
> That leaves
>
> [...]
OK, then it's not what you have searched for. As I don't know the
details that are missing I cannot really help more than this.
Sorry
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Patricia Shanahan <pa...@acm.org>.
On 8/9/2016 3:12 PM, Marcus wrote:
...
> we have a documented release process here [1]. Of course it's for a full
> release. But for a bugfix (or emergency) release it can be derived and
> then shortend.
>
> [1]
> https://cwiki.apache.org/confluence/display/OOOUSERS/Release+Planning+Template
That is the documentation I found before. Looking only at the steps
labeled "Release Manager", I do know how to make announcements on
mailing lists, even if I do sometimes get into autocomplete tangles and
pick the wrong list, and how to run votes.
That leaves
"Update RN with new languages"
"Start release blocker mode (aka show stopper mode)"
"Commit changes to reflect the upcoming release:
Version number, build ID, build date+time, copyright year"
(I do know how to commit changes to svn, but not which file or files to
modify)
"Build the RC"
"Update Wiki page to make the files available
Development Snapshot Build
Make sure the files have the correct access permissions"
"Upload files to Apache Dist/SourceForge
Make sure to set the staging bit for the Beta directory"
"Create a "kid" build:
This helpful and often asked for translation testing.
Announce it on dev@, qa@, l10n@"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Marcus <ma...@wtnet.de>.
Am 08/09/2016 11:07 PM, schrieb Patricia Shanahan:
>
>
> On 8/9/2016 8:52 AM, Kay Schenk@apache.org wrote:
>>
>>
>> On 08/08/2016 09:26 PM, Patricia Shanahan wrote:
>>> On 8/8/2016 11:14 AM, Marcus wrote:
>>>> Am 08/08/2016 07:28 PM, schrieb Andrea Pescetti:
>>>>> On 07/08/2016 Marcus wrote:
>>>>>> Maybe we are not that far aways from each other. What I want to to
>>>>>> avoid
>>>>>> is to provide hundreads of MBs for a single fix. Of course we can
>>>>>> do a
>>>>>> 4.1.3 with some collected fixes. As I don't know what is coming in
>>>>>> the
>>>>>> future I would not love to see another 4.1.4, 4.1.5, 4.1.6, etc. when
>>>>>> the calendar is still showing 2016. ;-)
>>>>>
>>>>> The right trade-off would be between two and three releases a year
>>>>> (including maintenance releases).
>>>>>
>>>>> Based on history, we've never been -and we are not- in a "release now
>>>>> since there is a known critical exploit circulating", so the
>>>>> "emergency
>>>>> release" is not likely to happen often.
>>>>>
>>>>> It will be enough to be in a permanent "ready to release" mode (where
>>>>> work is still mostly on the infrastructure side, the rest is OK)
>>>>> and use
>>>>> this readiness to ship emergency releases in the unlikely case we need
>>>>> one, and a few maintenance/feature releases from time to time.
>>>>
>>>> it seems we have the same wish with regard to releases. We can just
>>>> hope
>>>> that this can come true.
>>>>
>>>
>>> +1 on "ready to release" mode. However, rather than just hoping it can
>>> come true, I would like to work on a plan to make it come true.
>>>
>>
>> Some ideas about steps:
>>
>> * an "ongoing" or permanent release manager.
>
> I think several of us should train as release manager, and the role
> should be moved around. For example, I can't commit as "permanent"
> release manager, or even as release manager for the next year, because I
> have vacations planned that will leave me with no access to my home
> computers and limited Internet access for two or three weeks at a time.
> That should not prevent me from serving as release manager for limited
> terms during which I expect to be home.
>
> I do think that there should always be a designated release manager.
>
> How do we go about getting trained as release manager? Documenting the
> process in more detail?
>
> Once we get into the ready-to-release mode it will get a lot easier to
> train. We will be doing most of the steps regularly, stopping just short
> of actually releasing.
>
>> * a quick turnarond on issues inclusion. Currently, we take quite a
>> while with this.
>
> I envisage always having a branch or tag, managed by the release
> manager, that represents the ready release. An emergency release would
> take that branch, add one security fix, and complete the release process.
>
>>
>> This would be at a minimum.
>>
>> It is not impossible and really not all that difficult to spin off JUST
>> the rpms or deb packages to deal with specific issues for Linux. This
>> would be an enhancement to just distributing files as with our current
>> patches. The same probably can not be said of Windows or Mac, however.
we have a documented release process here [1]. Of course it's for a full
release. But for a bugfix (or emergency) release it can be derived and
then shortend.
[1]
https://cwiki.apache.org/confluence/display/OOOUSERS/Release+Planning+Template
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Andrea Pescetti <pe...@apache.org>.
On 10/08/2016 Patricia Shanahan wrote:
> On 8/9/2016 2:41 PM, Andrea Pescetti wrote:
>> Patricia Shanahan wrote:
>>> How do we go about getting trained as release manager?
>> By making a release, or two.
> If we only do two or three releases a year, we will only be able to
> train release managers are a rate of about two a year. Is that fast
> enough to be able to ensure we always have a designated release manager?
We don't need 50 release managers. We need a community-wide
understanding of various issues related to releases, so one properly
communicated release can be enough to get many people trained. You will
find out that most of the work cannot be documented: making a release is
a community effort, requiring coordination and collective thinking; the
technical/predictable part is minor.
> Last time I tried finding documentation I found a lot about what steps
> were needed, but very little about how to actually do the steps.
Start with the first step. Continuing this discussion just for the sake
of talking won't help anyone. So, if you are volunteering for
coordinating a 4.1.3 release, just start a thread about it, describe
what you believe should go into it and what not. This may of course
change with time; start with a reasonable assumption and then the
release will contain something more or something less depending on what
others do.
But again, don't worry too much about the process. A lot of people here
are familiar with releases and may be able to help. For sure we won't
settle on weekly releases, but on the other side we shouldn't let one
year pass since our 4.1.2 release before making another one. (I would
prefer to focus on 4.2.0, but that is another matter and you feel more
confident in coordinating a 4.1.3 release I'll help you nonetheless;
just start).
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Patricia Shanahan <pa...@acm.org>.
On 8/9/2016 2:41 PM, Andrea Pescetti wrote:
> Patricia Shanahan wrote:
>> How do we go about getting trained as release manager?
>
> By making a release, or two.
If we only do two or three releases a year, we will only be able to
train release managers are a rate of about two a year. Is that fast
enough to be able to ensure we always have a designated release manager?
>
>> Documenting the process in more detail?
>
> You can see the whole process documented everywhere (ASF pages and CWiki
> for the 4.1.2 release), but it's a matter of tooling at this stage more
> than documentation. Documentation was the main aim of 4.1.2.
Last time I tried finding documentation I found a lot about what steps
were needed, but very little about how to actually do the steps.
>
>> I envisage always having a branch or tag, managed by the release
>> manager, that represents the ready release. An emergency release would
>> take that branch, add one security fix, and complete the release process.
>
> There is really nothing to invent or to do in a special way here. Our
> codebase uses a (more or less) conventional approach. It can be tweaked
> and perfected, but there's not much to discuss or change in this respect.
>
> Regards,
> Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Andrea Pescetti <pe...@apache.org>.
Patricia Shanahan wrote:
> How do we go about getting trained as release manager?
By making a release, or two.
> Documenting the process in more detail?
You can see the whole process documented everywhere (ASF pages and CWiki
for the 4.1.2 release), but it's a matter of tooling at this stage more
than documentation. Documentation was the main aim of 4.1.2.
> I envisage always having a branch or tag, managed by the release
> manager, that represents the ready release. An emergency release would
> take that branch, add one security fix, and complete the release process.
There is really nothing to invent or to do in a special way here. Our
codebase uses a (more or less) conventional approach. It can be tweaked
and perfected, but there's not much to discuss or change in this respect.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Patricia Shanahan <pa...@acm.org>.
On 8/9/2016 8:52 AM, Kay Schenk@apache.org wrote:
>
>
> On 08/08/2016 09:26 PM, Patricia Shanahan wrote:
>> On 8/8/2016 11:14 AM, Marcus wrote:
>>> Am 08/08/2016 07:28 PM, schrieb Andrea Pescetti:
>>>> On 07/08/2016 Marcus wrote:
>>>>> Maybe we are not that far aways from each other. What I want to to
>>>>> avoid
>>>>> is to provide hundreads of MBs for a single fix. Of course we can do a
>>>>> 4.1.3 with some collected fixes. As I don't know what is coming in the
>>>>> future I would not love to see another 4.1.4, 4.1.5, 4.1.6, etc. when
>>>>> the calendar is still showing 2016. ;-)
>>>>
>>>> The right trade-off would be between two and three releases a year
>>>> (including maintenance releases).
>>>>
>>>> Based on history, we've never been -and we are not- in a "release now
>>>> since there is a known critical exploit circulating", so the "emergency
>>>> release" is not likely to happen often.
>>>>
>>>> It will be enough to be in a permanent "ready to release" mode (where
>>>> work is still mostly on the infrastructure side, the rest is OK) and use
>>>> this readiness to ship emergency releases in the unlikely case we need
>>>> one, and a few maintenance/feature releases from time to time.
>>>
>>> it seems we have the same wish with regard to releases. We can just hope
>>> that this can come true.
>>>
>>
>> +1 on "ready to release" mode. However, rather than just hoping it can
>> come true, I would like to work on a plan to make it come true.
>>
>
> Some ideas about steps:
>
> * an "ongoing" or permanent release manager.
I think several of us should train as release manager, and the role
should be moved around. For example, I can't commit as "permanent"
release manager, or even as release manager for the next year, because I
have vacations planned that will leave me with no access to my home
computers and limited Internet access for two or three weeks at a time.
That should not prevent me from serving as release manager for limited
terms during which I expect to be home.
I do think that there should always be a designated release manager.
How do we go about getting trained as release manager? Documenting the
process in more detail?
Once we get into the ready-to-release mode it will get a lot easier to
train. We will be doing most of the steps regularly, stopping just short
of actually releasing.
> * a quick turnarond on issues inclusion. Currently, we take quite a
> while with this.
I envisage always having a branch or tag, managed by the release
manager, that represents the ready release. An emergency release would
take that branch, add one security fix, and complete the release process.
>
> This would be at a minimum.
>
> It is not impossible and really not all that difficult to spin off JUST
> the rpms or deb packages to deal with specific issues for Linux. This
> would be an enhancement to just distributing files as with our current
> patches. The same probably can not be said of Windows or Mac, however.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by "Kay Schenk@apache.org" <ks...@apache.org>.
On 08/08/2016 09:26 PM, Patricia Shanahan wrote:
> On 8/8/2016 11:14 AM, Marcus wrote:
>> Am 08/08/2016 07:28 PM, schrieb Andrea Pescetti:
>>> On 07/08/2016 Marcus wrote:
>>>> Maybe we are not that far aways from each other. What I want to to
>>>> avoid
>>>> is to provide hundreads of MBs for a single fix. Of course we can do a
>>>> 4.1.3 with some collected fixes. As I don't know what is coming in the
>>>> future I would not love to see another 4.1.4, 4.1.5, 4.1.6, etc. when
>>>> the calendar is still showing 2016. ;-)
>>>
>>> The right trade-off would be between two and three releases a year
>>> (including maintenance releases).
>>>
>>> Based on history, we've never been -and we are not- in a "release now
>>> since there is a known critical exploit circulating", so the "emergency
>>> release" is not likely to happen often.
>>>
>>> It will be enough to be in a permanent "ready to release" mode (where
>>> work is still mostly on the infrastructure side, the rest is OK) and use
>>> this readiness to ship emergency releases in the unlikely case we need
>>> one, and a few maintenance/feature releases from time to time.
>>
>> it seems we have the same wish with regard to releases. We can just hope
>> that this can come true.
>>
>
> +1 on "ready to release" mode. However, rather than just hoping it can
> come true, I would like to work on a plan to make it come true.
>
Some ideas about steps:
* an "ongoing" or permanent release manager.
* a quick turnarond on issues inclusion. Currently, we take quite a
while with this.
This would be at a minimum.
It is not impossible and really not all that difficult to spin off JUST
the rpms or deb packages to deal with specific issues for Linux. This
would be an enhancement to just distributing files as with our current
patches. The same probably can not be said of Windows or Mac, however.
--
Kay Schenk
Apache OpenOffice
----------------------------------------
"Things work out best for those who make
the best of the way things work out."
-- John Wooden
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Patricia Shanahan <pa...@acm.org>.
On 8/8/2016 11:14 AM, Marcus wrote:
> Am 08/08/2016 07:28 PM, schrieb Andrea Pescetti:
>> On 07/08/2016 Marcus wrote:
>>> Maybe we are not that far aways from each other. What I want to to avoid
>>> is to provide hundreads of MBs for a single fix. Of course we can do a
>>> 4.1.3 with some collected fixes. As I don't know what is coming in the
>>> future I would not love to see another 4.1.4, 4.1.5, 4.1.6, etc. when
>>> the calendar is still showing 2016. ;-)
>>
>> The right trade-off would be between two and three releases a year
>> (including maintenance releases).
>>
>> Based on history, we've never been -and we are not- in a "release now
>> since there is a known critical exploit circulating", so the "emergency
>> release" is not likely to happen often.
>>
>> It will be enough to be in a permanent "ready to release" mode (where
>> work is still mostly on the infrastructure side, the rest is OK) and use
>> this readiness to ship emergency releases in the unlikely case we need
>> one, and a few maintenance/feature releases from time to time.
>
> it seems we have the same wish with regard to releases. We can just hope
> that this can come true.
>
+1 on "ready to release" mode. However, rather than just hoping it can
come true, I would like to work on a plan to make it come true.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Marcus <ma...@wtnet.de>.
Am 08/08/2016 07:28 PM, schrieb Andrea Pescetti:
> On 07/08/2016 Marcus wrote:
>> Maybe we are not that far aways from each other. What I want to to avoid
>> is to provide hundreads of MBs for a single fix. Of course we can do a
>> 4.1.3 with some collected fixes. As I don't know what is coming in the
>> future I would not love to see another 4.1.4, 4.1.5, 4.1.6, etc. when
>> the calendar is still showing 2016. ;-)
>
> The right trade-off would be between two and three releases a year
> (including maintenance releases).
>
> Based on history, we've never been -and we are not- in a "release now
> since there is a known critical exploit circulating", so the "emergency
> release" is not likely to happen often.
>
> It will be enough to be in a permanent "ready to release" mode (where
> work is still mostly on the infrastructure side, the rest is OK) and use
> this readiness to ship emergency releases in the unlikely case we need
> one, and a few maintenance/feature releases from time to time.
it seems we have the same wish with regard to releases. We can just hope
that this can come true.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Andrea Pescetti <pe...@apache.org>.
On 07/08/2016 Marcus wrote:
> Maybe we are not that far aways from each other. What I want to to avoid
> is to provide hundreads of MBs for a single fix. Of course we can do a
> 4.1.3 with some collected fixes. As I don't know what is coming in the
> future I would not love to see another 4.1.4, 4.1.5, 4.1.6, etc. when
> the calendar is still showing 2016. ;-)
The right trade-off would be between two and three releases a year
(including maintenance releases).
Based on history, we've never been -and we are not- in a "release now
since there is a known critical exploit circulating", so the "emergency
release" is not likely to happen often.
It will be enough to be in a permanent "ready to release" mode (where
work is still mostly on the infrastructure side, the rest is OK) and use
this readiness to ship emergency releases in the unlikely case we need
one, and a few maintenance/feature releases from time to time.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Marcus <ma...@wtnet.de>.
Am 08/07/2016 06:14 PM, schrieb Patricia Shanahan:
>
> On 8/7/2016 8:29 AM, Marcus wrote:
> ...
>> I don't want to have it perfect. And we are already in this emergency
>> situation. We have either a patch process nor a full-release process.
>
> We don't have what I consider to be the full emergency, a live exploit
> in the field.
OK, ACK.
> Why not both strategies? Go ahead with the inferior, clumsy,
> user-hostile patch process because that is the best we can do this week,
I would do it (or help) when I had some knowledge in Windows batch
programming. Unfortunately ...
> but meanwhile work on getting competent at preparing a full release
> promptly if needed.
Maybe we are not that far aways from each other. What I want to to avoid
is to provide hundreads of MBs for a single fix. Of course we can do a
4.1.3 with some collected fixes. As I don't know what is coming in the
future I would not love to see another 4.1.4, 4.1.5, 4.1.6, etc. when
the calendar is still showing 2016. ;-)
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Patricia Shanahan <pa...@acm.org>.
On 8/7/2016 8:29 AM, Marcus wrote:
...
> I don't want to have it perfect. And we are already in this emergency
> situation. We have either a patch process nor a full-release process.
We don't have what I consider to be the full emergency, a live exploit
in the field.
Why not both strategies? Go ahead with the inferior, clumsy,
user-hostile patch process because that is the best we can do this week,
but meanwhile work on getting competent at preparing a full release
promptly if needed.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Marcus <ma...@wtnet.de>.
Am 08/06/2016 12:57 AM, schrieb Patricia Shanahan:
> 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.
I don't understand what you meant. At the end you would repaint your
whole car when you have just a scratch?
> 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.
OK, sure, nowadays it's really very smooth. But I don't wanna point out
how perfect or good looking the process is. They provide singles file.
Thats it.
> 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.
I don't want to have it perfect. And we are already in this emergency
situation. We have either a patch process nor a full-release process.
I'm still not convinced that we should work on a new full release
process at this point. I'm pretty sure it's not ready until end of the
month.
But we have already the patched library files. From the testing feedback
what I've seen so far, it seems we have no problems with them (OK, no
feedback from Mac OSX until now).
But as always it's just my opinion. If we all decide to work out a new
full release for this fix, then this should be the way.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Patricia Shanahan <pa...@acm.org>.
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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Planning for emergency releases
Posted by Marcus <ma...@wtnet.de>.
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.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org