Re: Planning for emergency releases

[Andrea Pescetti]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Planning for emergency releases

[Patricia Shanahan]

On 8/12/2016 2:14 PM, Dennis E. Hamilton wrote:




-Original Message- From: Patricia Shanahan
[mailto:p...@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 bo...@apache.org, is that if the ASF Board ever gets involved,
they will swing hammers not scalpels.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: Planning for emergency releases

[Dennis E. Hamilton]

> -Original Message-
> From: Patricia Shanahan [mailto:p...@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:p...@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-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Planning for emergency releases

[Patricia Shanahan]

On 8/12/2016 1:40 PM, Dennis E. Hamilton wrote:

-Original Message- From: Patricia Shanahan
[mailto:p...@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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: Planning for emergency releases

[Dennis E. Hamilton]

> -Original Message-
> From: Patricia Shanahan [mailto:p...@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-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Planning for emergency releases

[Patricia Shanahan]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Planning for emergency releases

[Marcus]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Planning for emergency releases

[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

"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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Planning for emergency releases

[Marcus]

Am 08/09/2016 11:07 PM, schrieb Patricia Shanahan:



On 8/9/2016 8:52 AM, Kay sch...@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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Planning for emergency releases

[Patricia Shanahan]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Planning for emergency releases

[Andrea Pescetti]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Planning for emergency releases

[Patricia Shanahan]

On 8/9/2016 8:52 AM, Kay sch...@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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Planning for emergency releases

[Kay sch...@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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: Planning for emergency releases

[Dennis E. Hamilton]

> -Original Message-
> From: Patricia Shanahan [mailto:p...@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-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Planning for emergency releases

[Patricia Shanahan]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: Planning for emergency releases

[Dennis E. Hamilton]

+1 on the permanent "ready to release" mode.

> -Original Message-
> From: Marcus [mailto:marcus.m...@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-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Planning for emergency releases

[Marcus]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Planning for emergency releases

[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.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Planning for emergency releases

[Marcus]

Am 08/07/2016 07:38 PM, schrieb Dennis E. Hamilton:




-Original Message-
From: Marcus [mailto:marcus.m...@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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Planning for emergency releases

[Patricia Shanahan]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: Planning for emergency releases

[Dennis E. Hamilton]

> -Original Message-
> From: Marcus [mailto:marcus.m...@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-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Planning for emergency releases

[Marcus]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Planning for emergency releases

[Marcus]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Planning for emergency releases

[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.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Planning for emergency releases

[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.

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Planning for emergency releases

[Marcus]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Planning for emergency releases

[Marcus]

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  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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: Planning for emergency releases

[Dennis E. Hamilton]

> -Original Message-
> From: Marcus [mailto:marcus.m...@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-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Planning for emergency releases

[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.

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

Re: Planning for emergency releases

[Dave Fisher]

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  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-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Planning for emergency releases

[Marcus]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org