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
