openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <>
Subject Re: release manager for the next release
Date Mon, 06 Oct 2014 16:37:59 GMT

On 10/06/2014 12:33 AM, Jürgen Schmidt wrote:
> On 05/10/14 19:06, Kay Schenk wrote:
>> On Sun, Oct 5, 2014 at 2:21 AM, jan i <> wrote:
>>> On 4 October 2014 22:08, Andrea Pescetti <> wrote:
>>>> On 04/10/2014 jan i wrote:
>>>>> Thanks jürgen for the work you have done.
>>>> Sure, thanks Juergen for being a great, reliable and patient release
>>>> manager during these years.
>>>>  In other words, I strongly believe we have to depend on non-apache
>>>>> hardware
>>>>> to produce a major part of the binaries. A new release manager should
>>>>> provide or have access to several VMs in order to cut the release. It
>>> has
>>>>> always looked as if Jürgen had direct or indirect access to all the
>>>>> platforms needed.
>>>> Well, this is a thing we must change. Ideally, we must be able to produce
>>>> all binaries at Apache for the next release. We are now depending on
>>>> individual developers providing their own systems, but this won't work
>>> for
>>>> other ongoing activities too (like signing releases). If you look at the
>>>> Infra list recent discussions, it seems we will be able to get our hands
>>> on
>>>> suitable Mac hardware soon.
>>>> So in short: a new release is not going to happen before we have fixed
>>> the
>>>> release process. Part of this fix can be very challenging, like bringing
>>>> all building activities to Apache hardware. But we shouldn't expect that
>>>> what a release manager needs NOW is valid for the NEXT release.
>>> Same time last year, the Apple hardware was signed for ordering, when Infra
>>> found out it lacked budget. This year the discussion goes, "no more
>>> hardware until what we have runs", and that is assumed to take until first
>>> part of 2015. So in other words dont put up too high hopes. Have a look at
>>> the jira ticket instead.
>>> Furthermore, please remember, AOO cannot cimpile on a standard Apple
>>> platform, we need some old (outdated unsupported apple libraries/tools
>>> installed, that makes the machine useless (or at the very least very
>>> difficult) to use for projects that want to use the newest apple platform.
>> I hope we can get some clarification on the above statement --
>> " old (outdated unsupported apple libraries/tools
>> installed"
>> esp with respect to Mac since we recently dropped support for anything
>> below 10.7.
>> In any case,  reassessing the  library/other externals versions for all
>> platforms is definitely in order.
> simply spoken a wrong or misleading info from Jan, the last AOO release
> was made on the latest MacOS version (at this time) with XCode 5.
> Missing Apple hardware is one problem for one platform.


for latest on the Mac situation. I guess the ball is back in our court
on this one.

 Missing Linux
> system with proper baseline is the other one that can be addressed by
> providing VMs with a suitable system.
> My hope is that we can find consensus with infra about this and can have
> such VMs soon.
> Juergen

You're referring to the CentOS VM ticket?

What would we be using for Linux-32?

>>>>  A release manager does not need to be PMC, but only the PMC have binding
>>>>> votes for a release......this can theoritically lead to a situation
>>> where
>>>>> the vote ends with only +1, but the release manager gives a non-binding
>>>>> -1.
>>>>> If nothing else that should lead to a funny board report.
>>>> This is a theoretical case. The Release Manager is trusted. If I receive
>>> a
>>>> -1 from the Release Manager, I'll immediately change my +1 vote to a -1
>>> and
>>>> so will do other PMC members. Let's focus on concrete discussions.
>>>>  Ps. it seems markmail does not support inline responses, or am I doing
>>>>> something wrong ?
>>>> I'll be BCCing you in my responses to your messages so at least we don't
>>>> break threads.
>>> thanks but really not needed, I unsubscribed from the list in order to be
>>> able to check the dev mails when I want to, without having my mailbox
>>> filled up. I can see that I do not break threads, but merely cannot respond
>>> inline.
>>> rgds
>>> jan I
>>>> Regards,
>>>>   Andrea.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:


"The universe is full of magical things
 patiently waiting for our wits to grow sharper."
                         -- Eden Phillpotts

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message