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
