Re: Staging 4.1.2 (was RE: Budapest and thereafter.)

[Andrea Pescetti]

On 15/12/2014 Pedro Giffuni wrote:

Il giorno 14/dic/2014, alle ore 17:20, Andrea Pescetti ha scritto:
On 14/12/2014 Dennis E. Hamilton wrote:

https://svn.apache.org/repos/asf/openoffice/trunk/main/writerperfect/
at revision 1645375. ...
I think it would be good to have a stronger check for 4.1.2 though.

I'm CCing Pedro who told me something similar (possibly the very same issue)

Yes. According to my records the PMC was notified


OK, I verified that everything builds fine without it and I removed 
main/writerperfect:

http://svn.apache.org/viewvc?view=revision&revision=1648122

Please note that the status is not completely clear, see 
https://issues.apache.org/ooo/show_bug.cgi?id=118919 for more (but if we 
are not using it, maybe the discussion is not worth it anyway).


Regards,
  Andrea.

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

Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)

[Andrea Pescetti]

On 13/12/2014 jan i wrote:

8.1 and above, it complains when you start the exe after installation.


To people who were waiting for developments in this discussion: a new 
one ("Digital signing release for windows") has been started, so please 
follow it and I'll post my replies there too. See also the "OpenOffice 
and Infrastructure: ApacheCon meeting" discussion. Contrary to popular 
belief, nothing useful to our purpose was discussed on private lists.


Regards,
  Andrea.

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

Re: Budapest and thereafter.

[Andrea Pescetti]

On 17/12/2014 Jürgen Schmidt wrote:

On 16/12/14 16:02, Andrea Pescetti wrote:

And you are volunteering to do the same (i.e., provide builds from your
own machines) for 4.1.2? ...

this is something that is possible and I would like to move this to
later when we come closer to a release date.


OK, thanks!


I will for sure not able to
provide dev snapshot on a regular basis because the lack of time.


Then it makes sense to continue with the current approach in order to 
have dev snapshot that are very close to release builds.


Regards,
  Andrea.

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

Re: Budapest and thereafter.

[Jürgen Schmidt]

On 16/12/14 16:02, Andrea Pescetti wrote:
> Jürgen Schmidt wrote:
>> I have built the release on private machines. Means a local windows build
>> machine, local Linux CentOS build VMs and of course my Mac prepared with
>> the proper baseline.
> 
> And you are volunteering to do the same (i.e., provide builds from your
> own machines) for 4.1.2? This is what matters to me, actually, in case I
> wasn't clear.

this is something that is possible and I would like to move this to
later when we come closer to a release date. I will for sure not able to
provide dev snapshot on a regular basis because the lack of time.

Juergen



> 
> 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: Budapest and thereafter.

[Andrea Pescetti]

Jürgen Schmidt wrote:

I have built the release on private machines. Means a local windows build
machine, local Linux CentOS build VMs and of course my Mac prepared with
the proper baseline.


And you are volunteering to do the same (i.e., provide builds from your 
own machines) for 4.1.2? This is what matters to me, actually, in case I 
wasn't clear.


Regards,
  Andrea.

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

Re: Budapest and thereafter.

[jan i]

On Tuesday, December 16, 2014, Jürgen Schmidt  wrote:

> On 14/12/14 10:10, Andrea Pescetti wrote:
> > On 14/12/2014 jan i wrote:
> >> On Saturday, December 13, 2014, Andrea Pescetti wrote:
> >>> Very honestly, I would like that we don't depend on individuals for
> >>> project resources, but maybe it is easier for a developer to share an
> >>> existing virtual machine (and possibly get it running at Apache) than
> to
> >>> prepare a buildbot environment.
> >> equally honest I would be happy if we just had 1 person prepared to do
> >> the
> >> job. Wishing for multiple people is a luxury I  don't think we can
> >> afford.
> >
> > Ah no, sorry, I didn't mean that (i.e., individuals opposed to groups).
> > I meant: resources that are important for the project (like: the machine
> > used to build our released binaries) should not be under the control of
> > individuals. Compare: a VM used to build releases that is hosted on one
> > developer's workstation, and is thus unreachable to other project
> > members, and the same VM hosted at Apache where we can arrange access to
> > other project members when needed/desired.
> >
> >> none of our buildbots run with release setting (something I have
> >> advocated
> >> for a long time), so its unlikely that any asf vm was used.
> >
> > OK, so let's wait a couple days for more details, since this is quite
> > important: I know that Juergen builds Mac on his own hardware, but I
> > don't know about the rest.
>
> I wondering a bit why this is new to anybody. Based on the fact that the
> ASF Linux bots had a different baseline and the windows machine also
> lacks some important parts for some time (can't remember for sure) I
> have built the release on private machines. Means a local windows build
> machine, local Linux CentOS build VMs and of course my Mac prepared with
> the proper baseline.
>
> But this no big thing and ones the CentOS VMs are in place it is easy to
> use the same settings that are probably still the same as documented on
> our dev snapshot wiki page. Maybe minor changes regarding languages.
> Anyway we can quite easy compare it.
>
> Andre Rist got my build scripts for Mac already and I offered my help...
>
> Nothing special new we just did it and didn't wait on somebody else.

+1 less talk, less waiting  more doing !

jan i

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

-- 
Sent from My iPad, sorry for any misspellings.

Re: Budapest and thereafter.

[Jürgen Schmidt]

On 14/12/14 10:10, Andrea Pescetti wrote:
> On 14/12/2014 jan i wrote:
>> On Saturday, December 13, 2014, Andrea Pescetti wrote:
>>> Very honestly, I would like that we don't depend on individuals for
>>> project resources, but maybe it is easier for a developer to share an
>>> existing virtual machine (and possibly get it running at Apache) than to
>>> prepare a buildbot environment.
>> equally honest I would be happy if we just had 1 person prepared to do
>> the
>> job. Wishing for multiple people is a luxury I  don't think we can
>> afford.
> 
> Ah no, sorry, I didn't mean that (i.e., individuals opposed to groups).
> I meant: resources that are important for the project (like: the machine
> used to build our released binaries) should not be under the control of
> individuals. Compare: a VM used to build releases that is hosted on one
> developer's workstation, and is thus unreachable to other project
> members, and the same VM hosted at Apache where we can arrange access to
> other project members when needed/desired.
> 
>> none of our buildbots run with release setting (something I have
>> advocated
>> for a long time), so its unlikely that any asf vm was used.
> 
> OK, so let's wait a couple days for more details, since this is quite
> important: I know that Juergen builds Mac on his own hardware, but I
> don't know about the rest.

I wondering a bit why this is new to anybody. Based on the fact that the
ASF Linux bots had a different baseline and the windows machine also
lacks some important parts for some time (can't remember for sure) I
have built the release on private machines. Means a local windows build
machine, local Linux CentOS build VMs and of course my Mac prepared with
the proper baseline.

But this no big thing and ones the CentOS VMs are in place it is easy to
use the same settings that are probably still the same as documented on
our dev snapshot wiki page. Maybe minor changes regarding languages.
Anyway we can quite easy compare it.

Andre Rist got my build scripts for Mac already and I offered my help...

Nothing special new we just did it and didn't wait on somebody else.

Juergen

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

Re: Staging 4.1.2 (was RE: Budapest and thereafter.)

[Pedro Giffuni]

Hello;

> Il giorno 14/dic/2014, alle ore 17:20, Andrea Pescetti  
> ha scritto:
> 
> On 14/12/2014 Dennis E. Hamilton wrote:
>> Looking at
>> aoo-4.1.1/writerperfect/source/filter/DocumentCollector.cxx, the first
>> one I chose to examine, I see three Copyright notices and an LGPL
>> license notice in the comments at the top of the file.
>> The same file, and the others, appear at
>> 
>> as well as 
>> 
>> at revision 1645375. ...
>> I think it would be good to have a stronger check for 4.1.2 though.
> 
> I'm CCing Pedro who told me something similar (possibly the very same issue) 
> at ApacheCon last month. If I understand correctly, these files are unused 
> for the build and should simply be removed.
> 
> Regards,
>  Andrea.

Yes. According to my records the PMC was notified about a couple of licensing 
issues, including this one, on March 12, 2014.

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

RE: Staging 4.1.2 (was RE: Budapest and thereafter.)

[Dennis E. Hamilton]

I agree. If the build doesn't depend on them being there in some manner, simple 
removal of the writerperfect directory from the trunk should be sufficient.  If 
there is a config dependency for creating builds, that should be removed as 
well.

 - Dennis

-Original Message-
From: Andrea Pescetti [mailto:pesce...@apache.org] 
Sent: Sunday, December 14, 2014 14:20
To: dev@openoffice.apache.org; Pedro Giffuni
Subject: Re: Staging 4.1.2 (was RE: Budapest and thereafter.)

On 14/12/2014 Dennis E. Hamilton wrote:
> Looking at
> aoo-4.1.1/writerperfect/source/filter/DocumentCollector.cxx, the first
> one I chose to examine, I see three Copyright notices and an LGPL
> license notice in the comments at the top of the file.
> The same file, and the others, appear at
> <https://svn.apache.org/repos/asf/openoffice/branches/AOO410/main/writerperfect/>
> as well as 
> <https://svn.apache.org/repos/asf/openoffice/trunk/main/writerperfect/>
> at revision 1645375. ...
> I think it would be good to have a stronger check for 4.1.2 though.

I'm CCing Pedro who told me something similar (possibly the very same 
issue) at ApacheCon last month. If I understand correctly, these files 
are unused for the build and should simply be removed.

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: Staging 4.1.2 (was RE: Budapest and thereafter.)

[Andrea Pescetti]

On 14/12/2014 Dennis E. Hamilton wrote:

Looking at
aoo-4.1.1/writerperfect/source/filter/DocumentCollector.cxx, the first
one I chose to examine, I see three Copyright notices and an LGPL
license notice in the comments at the top of the file.
The same file, and the others, appear at

as well as 

at revision 1645375. ...
I think it would be good to have a stronger check for 4.1.2 though.


I'm CCing Pedro who told me something similar (possibly the very same 
issue) at ApacheCon last month. If I understand correctly, these files 
are unused for the build and should simply be removed.


Regards,
  Andrea.

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

RE: Staging 4.1.2 (was RE: Budapest and thereafter.)

[Dennis E. Hamilton]

Correction:

" The RAT scan linked to in the [VOTE] message for 4.1.1 lists only seven files 
for aoo410/main/writerperfect." (not aoo401)


-Original Message-
From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] 
Sent: Saturday, December 13, 2014 17:00
To: dev@openoffice.apache.org
Subject: RE: Staging 4.1.2 (was RE: Budapest and thereafter.)

OK, here is why I was looking for this.  Thanks for the links, Kay.

The RAT scan linked to in the [VOTE] message for 4.1.1 lists only seven files 
for aoo401/main/writerperfect.

Looking in the apache-openoffice-4.1.1-r1517669-src.zip, I see 33 files that 
could have comments and notices.
Looking at aoo-4.1.1/writerperfect/source/filter/DocumentCollector.cxx, the 
first one I chose to examine, I see three Copyright notices and an LGPL license 
notice in the comments at the top of the file.

The same file, and the others, appear at 
<https://svn.apache.org/repos/asf/openoffice/branches/AOO410/main/writerperfect/>
as well as 
<https://svn.apache.org/repos/asf/openoffice/trunk/main/writerperfect/>
at revision 1645375.

I'm no expert on RAT.  I can't account for the peculiar situation.  I think it 
would be good to have a stronger check for 4.1.2 though.

- Dennis

-Original Message-
From: Kay Schenk [mailto:kay.sch...@gmail.com] 
Sent: Saturday, December 13, 2014 15:20
To: dev@openoffice.apache.org
Subject: Re: Staging 4.1.2 (was RE: Budapest and thereafter.)



On 12/13/2014 01:37 PM, Dennis E. Hamilton wrote:
> Looking around for some other matters, I notice there is no 4.1.1 branch in 
> the SVN.  Is this intentional?

yes...see the following mail threads
http://markmail.org/message/qrjxespr3di7dxh7
http://markmail.org/message/cpqm4zysz4sd4ley



[ ... ]


-
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: Budapest and thereafter.

[Andrea Pescetti]

On 14/12/2014 jan i wrote:

On Saturday, December 13, 2014, Andrea Pescetti wrote:

Very honestly, I would like that we don't depend on individuals for
project resources, but maybe it is easier for a developer to share an
existing virtual machine (and possibly get it running at Apache) than to
prepare a buildbot environment.

equally honest I would be happy if we just had 1 person prepared to do the
job. Wishing for multiple people is a luxury I  don't think we can afford.


Ah no, sorry, I didn't mean that (i.e., individuals opposed to groups). 
I meant: resources that are important for the project (like: the machine 
used to build our released binaries) should not be under the control of 
individuals. Compare: a VM used to build releases that is hosted on one 
developer's workstation, and is thus unreachable to other project 
members, and the same VM hosted at Apache where we can arrange access to 
other project members when needed/desired.



none of our buildbots run with release setting (something I have advocated
for a long time), so its unlikely that any asf vm was used.


OK, so let's wait a couple days for more details, since this is quite 
important: I know that Juergen builds Mac on his own hardware, but I 
don't know about the rest.


Regards,
  Andrea.

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

Re: Budapest and thereafter.

[jan i]

On Saturday, December 13, 2014, Andrea Pescetti  wrote:

> On 08/12/2014 jan i wrote:
>
>> So may I politely ask, what have changed, that we now believe this will
>> all
>> go away, and we can have it all solved in a short time ?
>>
>
> Not much has changed indeed. I pushed to have buildbots running before the
> release, but indeed if buildbots are problematic and the same volunteers
> who built the previous releases can still commit to doing so for the next
> one, it is no major problem.
>
> Very honestly, I would like that we don't depend on individuals for
> project resources, but maybe it is easier for a developer to share an
> existing virtual machine (and possibly get it running at Apache) than to
> prepare a buildbot environment.

 equally honest I would be happy if we just had 1 person prepared to do the
job. Wishing for multiple people is a luxury I  don't think we can afford.

>
>  do we really want to wait until this magically happens ?
>>
>
> No, since it won't magically happen. So, what is the minimum we can do for
> a 4.1.2 release? I would set it at:
> - New/updated translations
> - New/updated dictionaries
> - Bugfixes (to be discussed)
> - Signed Windows binaries
> - Binaries for all other systems as usual
>
> I can volunteer for the first two items (coordinating translations and
> adding/updating dictionaries).
>
> But I'm actually missing some information maybe. Out of the following
> releases, which ones were built on individuals' machines for 4.1.1? All?
> Some? And are these built in a VM that we could consider moving to Apache
> hardware or not?
> 1) Windows
> 2) Linux 64 bit (RPM+DEB)
> 3) Linux 32 bit (RPM+DEB)
> 4) Mac


none of our buildbots run with release setting (something I have advocated
for a long time), so its unlikely that any asf vm was used.

rgds
jan i

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

-- 
Sent from My iPad, sorry for any misspellings.

RE: Staging 4.1.2 (was RE: Budapest and thereafter.)

[Dennis E. Hamilton]

OK, here is why I was looking for this.  Thanks for the links, Kay.

The RAT scan linked to in the [VOTE] message for 4.1.1 lists only seven files 
for aoo401/main/writerperfect.

Looking in the apache-openoffice-4.1.1-r1517669-src.zip, I see 33 files that 
could have comments and notices.
Looking at aoo-4.1.1/writerperfect/source/filter/DocumentCollector.cxx, the 
first one I chose to examine, I see three Copyright notices and an LGPL license 
notice in the comments at the top of the file.

The same file, and the others, appear at 
<https://svn.apache.org/repos/asf/openoffice/branches/AOO410/main/writerperfect/>
as well as 
<https://svn.apache.org/repos/asf/openoffice/trunk/main/writerperfect/>
at revision 1645375.

I'm no expert on RAT.  I can't account for the peculiar situation.  I think it 
would be good to have a stronger check for 4.1.2 though.

- Dennis

-Original Message-
From: Kay Schenk [mailto:kay.sch...@gmail.com] 
Sent: Saturday, December 13, 2014 15:20
To: dev@openoffice.apache.org
Subject: Re: Staging 4.1.2 (was RE: Budapest and thereafter.)



On 12/13/2014 01:37 PM, Dennis E. Hamilton wrote:
> Looking around for some other matters, I notice there is no 4.1.1 branch in 
> the SVN.  Is this intentional?

yes...see the following mail threads
http://markmail.org/message/qrjxespr3di7dxh7
http://markmail.org/message/cpqm4zysz4sd4ley



[ ... ]


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

Re: Staging 4.1.2 (was RE: Budapest and thereafter.)

[Kay Schenk]

On 12/13/2014 01:37 PM, Dennis E. Hamilton wrote:
> Looking around for some other matters, I notice there is no 4.1.1 branch in 
> the SVN.  Is this intentional?

yes...see the following mail threads
http://markmail.org/message/qrjxespr3di7dxh7
http://markmail.org/message/cpqm4zysz4sd4ley




> 
>  - Dennis
> 
> -Original Message-
> From: Andrea Pescetti [mailto:pesce...@apache.org] 
> Sent: Saturday, December 13, 2014 12:45
> To: dev@openoffice.apache.org
> Subject: Re: Budapest and thereafter.
> 
> On 08/12/2014 jan i wrote:
>> So may I politely ask, what have changed, that we now believe this will all
>> go away, and we can have it all solved in a short time ?
> 
> Not much has changed indeed. I pushed to have buildbots running before 
> the release, but indeed if buildbots are problematic and the same 
> volunteers who built the previous releases can still commit to doing so 
> for the next one, it is no major problem.
> 
> Very honestly, I would like that we don't depend on individuals for 
> project resources, but maybe it is easier for a developer to share an 
> existing virtual machine (and possibly get it running at Apache) than to 
> prepare a buildbot environment.
> 
>> do we really want to wait until this magically happens ?
> 
> No, since it won't magically happen. So, what is the minimum we can do 
> for a 4.1.2 release? I would set it at:
> - New/updated translations
> - New/updated dictionaries
> - Bugfixes (to be discussed)
> - Signed Windows binaries
> - Binaries for all other systems as usual
> 
> I can volunteer for the first two items (coordinating translations and 
> adding/updating dictionaries).
> 
> But I'm actually missing some information maybe. Out of the following 
> releases, which ones were built on individuals' machines for 4.1.1? All? 
> Some? And are these built in a VM that we could consider moving to 
> Apache hardware or not?
> 1) Windows
> 2) Linux 64 bit (RPM+DEB)
> 3) Linux 32 bit (RPM+DEB)
> 4) Mac
> 
> 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
> 

-- 
-
MzK

"There's a bit of magic in everything,
  and some loss to even things out."
-- Lou Reed

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

Staging 4.1.2 (was RE: Budapest and thereafter.)

[Dennis E. Hamilton]

Looking around for some other matters, I notice there is no 4.1.1 branch in the 
SVN.  Is this intentional?

 - Dennis

-Original Message-
From: Andrea Pescetti [mailto:pesce...@apache.org] 
Sent: Saturday, December 13, 2014 12:45
To: dev@openoffice.apache.org
Subject: Re: Budapest and thereafter.

On 08/12/2014 jan i wrote:
> So may I politely ask, what have changed, that we now believe this will all
> go away, and we can have it all solved in a short time ?

Not much has changed indeed. I pushed to have buildbots running before 
the release, but indeed if buildbots are problematic and the same 
volunteers who built the previous releases can still commit to doing so 
for the next one, it is no major problem.

Very honestly, I would like that we don't depend on individuals for 
project resources, but maybe it is easier for a developer to share an 
existing virtual machine (and possibly get it running at Apache) than to 
prepare a buildbot environment.

> do we really want to wait until this magically happens ?

No, since it won't magically happen. So, what is the minimum we can do 
for a 4.1.2 release? I would set it at:
- New/updated translations
- New/updated dictionaries
- Bugfixes (to be discussed)
- Signed Windows binaries
- Binaries for all other systems as usual

I can volunteer for the first two items (coordinating translations and 
adding/updating dictionaries).

But I'm actually missing some information maybe. Out of the following 
releases, which ones were built on individuals' machines for 4.1.1? All? 
Some? And are these built in a VM that we could consider moving to 
Apache hardware or not?
1) Windows
2) Linux 64 bit (RPM+DEB)
3) Linux 32 bit (RPM+DEB)
4) Mac

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: Budapest and thereafter.

[Andrea Pescetti]

On 08/12/2014 jan i wrote:

So may I politely ask, what have changed, that we now believe this will all
go away, and we can have it all solved in a short time ?


Not much has changed indeed. I pushed to have buildbots running before 
the release, but indeed if buildbots are problematic and the same 
volunteers who built the previous releases can still commit to doing so 
for the next one, it is no major problem.


Very honestly, I would like that we don't depend on individuals for 
project resources, but maybe it is easier for a developer to share an 
existing virtual machine (and possibly get it running at Apache) than to 
prepare a buildbot environment.



do we really want to wait until this magically happens ?


No, since it won't magically happen. So, what is the minimum we can do 
for a 4.1.2 release? I would set it at:

- New/updated translations
- New/updated dictionaries
- Bugfixes (to be discussed)
- Signed Windows binaries
- Binaries for all other systems as usual

I can volunteer for the first two items (coordinating translations and 
adding/updating dictionaries).


But I'm actually missing some information maybe. Out of the following 
releases, which ones were built on individuals' machines for 4.1.1? All? 
Some? And are these built in a VM that we could consider moving to 
Apache hardware or not?

1) Windows
2) Linux 64 bit (RPM+DEB)
3) Linux 32 bit (RPM+DEB)
4) Mac

Regards,
  Andrea.

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

Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)

[jan i]

On Saturday, December 13, 2014, Dennis E. Hamilton 
wrote:

> It appears that running SignTool on an .exe is deceptively simple.
>
> I have some other tasks to complete before I can install a Microsoft SDK
> that has the tool.  I will try SignTool over the weekend.


That was actually what I did when testing the signing process, but bear in
mind you need a valid certificate.

I hope you will see the same as I did (and rob made a bet on) windows 8.0
and below accept that the installer is signed and everything is ok, with
8.1 and above, it complains when you start the exe after installation.

rgds
jan i

>
>  - Dennis
>
> -Original Message-
> From: Rob Weir [mailto:r...@robweir.com ]
> Sent: Tuesday, December 9, 2014 15:56
> To: dev@openoffice.apache.org ; Dennis Hamilton
> Subject: Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)
>
> On Tue, Dec 9, 2014 at 5:19 PM, Dennis E. Hamilton
> > wrote:
> [ ... ]
> > I don't understand why full rebuilds are required.  The only crucial
> file that needs signing is the .exe that is downloaded and extracts the
> actual setup files.  All it does is extract a number of fixed files and
> then run the extracted setup.exe.
> >
>
> [ ... ]
>
> Of course, nothing requires that we go for certification.   I bet if
> we just signed the outermost installer it would be satisfy earlier
> versions of Windows, antivirus apps and browsers that are doing this
> kind of check.So it might be worth doing just this minimum
> initially.
>
> Regards,
>
> -Rob
>
>
> > If a signed version of that .exe can be created, using the existing
> setups delivered with the current 4.1.1 .exe files, there is nothing else
> to do.  It has to be done once for each language, but that's it.  No full
> rebuilds, no new dates on files.  The extracted setups would be binary
> identical to each of the current ones for 4.1.1, so it is easy to verify
> that the signed .exe does not deliver anything but the already reviewed
> installs.
> >
> > That might be unworkable, but it is definitely worth seeing if it is
> possible rather than going through a full-up set of build processes.
> >
> [ ... ]
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> 
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 
>
>

-- 
Sent from My iPad, sorry for any misspellings.

RE: Signing AOO 4.1.1 (was RE: Budapest and thereafter)

[Dennis E. Hamilton]

It appears that running SignTool on an .exe is deceptively simple.

I have some other tasks to complete before I can install a Microsoft SDK that 
has the tool.  I will try SignTool over the weekend.

 - Dennis

-Original Message-
From: Rob Weir [mailto:r...@robweir.com] 
Sent: Tuesday, December 9, 2014 15:56
To: dev@openoffice.apache.org; Dennis Hamilton
Subject: Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)

On Tue, Dec 9, 2014 at 5:19 PM, Dennis E. Hamilton
 wrote:
[ ... ]
> I don't understand why full rebuilds are required.  The only crucial file 
> that needs signing is the .exe that is downloaded and extracts the actual 
> setup files.  All it does is extract a number of fixed files and then run the 
> extracted setup.exe.
>

[ ... ]

Of course, nothing requires that we go for certification.   I bet if
we just signed the outermost installer it would be satisfy earlier
versions of Windows, antivirus apps and browsers that are doing this
kind of check.So it might be worth doing just this minimum
initially.

Regards,

-Rob


> If a signed version of that .exe can be created, using the existing setups 
> delivered with the current 4.1.1 .exe files, there is nothing else to do.  It 
> has to be done once for each language, but that's it.  No full rebuilds, no 
> new dates on files.  The extracted setups would be binary identical to each 
> of the current ones for 4.1.1, so it is easy to verify that the signed .exe 
> does not deliver anything but the already reviewed installs.
>
> That might be unworkable, but it is definitely worth seeing if it is possible 
> rather than going through a full-up set of build processes.
>
[ ... ]


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

Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)

[Rob Weir]

On Tue, Dec 9, 2014 at 5:19 PM, Dennis E. Hamilton
 wrote:
> +1 (non-binding [;<) on PMC approval of any slip-stream.
>
> I don't understand why full rebuilds are required.  The only crucial file 
> that needs signing is the .exe that is downloaded and extracts the actual 
> setup files.  All it does is extract a number of fixed files and then run the 
> extracted setup.exe.
>

We found this out when we took AOO through the Windows 8 certification
testing tool.They have something new called "kernel-mode code
signing" where they check each exe, dll, sys , etc., for a digital
signature at load time.  So certification requires we sign any
executable code and then do it for the outermost installer as well.

Of course, nothing requires that we go for certification.   I bet if
we just signed the outermost installer it would be satisfy earlier
versions of Windows, antivirus apps and browsers that are doing this
kind of check.So it might be worth doing just this minimum
initially.

Regards,

-Rob


> If a signed version of that .exe can be created, using the existing setups 
> delivered with the current 4.1.1 .exe files, there is nothing else to do.  It 
> has to be done once for each language, but that's it.  No full rebuilds, no 
> new dates on files.  The extracted setups would be binary identical to each 
> of the current ones for 4.1.1, so it is easy to verify that the signed .exe 
> does not deliver anything but the already reviewed installs.
>
> That might be unworkable, but it is definitely worth seeing if it is possible 
> rather than going through a full-up set of build processes.
>
>  - Dennis
>
> PS: Rob's analysis is very useful to keep in mind as we look at other ways to 
> increase confidence in the AOO binaries and the AOO site as preferable for 
> those downloads.  I think grabbing the low-hanging fruit and getting 
> something simple through the process is also desirable, especially since we 
> are starting from zero using the signing process.
>
>
> -Original Message-
> From: jan i [mailto:j...@apache.org]
> Sent: Tuesday, December 9, 2014 08:29
> To: dev; Dennis Hamilton
> Subject: Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)
>
> On 9 December 2014 at 16:26, Dennis E. Hamilton 
> wrote:
>
>> Andrea,
>>
> [ ... ]
>> (Or even sign the existing installer
>> file, if it is in the proper format for inserting the information and
>> signature.)  That is, the .cab, .msi, and setup.exe would be completely
>> unchanged.
>>
> No we need to rebuild (and for every language), because the last step in
> the build process needs to be repeated, we cannot just patch the files.
>
> If we could move away from 1 install set pr language, the job would be
> about 30 times faster :-)
>
>
>
>
> AOO is special compared to most other projects, in that the majority of our
> users use the binary package. As a consequence, I recommend a PMC vote,
> even if its not strictly needed.
>
> [ ... ]
>
>>
>> It would still have to be project-managed in the sense that all of the
>> measures to preserve binary authenticity and provide accompanying binary
>> release management internal to AOO should be followed.
>>
> [ ... ]
>
>
> -
> 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: Signing AOO 4.1.1 (was RE: Budapest and thereafter)

[Dennis E. Hamilton]

+1 (non-binding [;<) on PMC approval of any slip-stream.

I don't understand why full rebuilds are required.  The only crucial file that 
needs signing is the .exe that is downloaded and extracts the actual setup 
files.  All it does is extract a number of fixed files and then run the 
extracted setup.exe.  

If a signed version of that .exe can be created, using the existing setups 
delivered with the current 4.1.1 .exe files, there is nothing else to do.  It 
has to be done once for each language, but that's it.  No full rebuilds, no new 
dates on files.  The extracted setups would be binary identical to each of the 
current ones for 4.1.1, so it is easy to verify that the signed .exe does not 
deliver anything but the already reviewed installs.  

That might be unworkable, but it is definitely worth seeing if it is possible 
rather than going through a full-up set of build processes.

 - Dennis

PS: Rob's analysis is very useful to keep in mind as we look at other ways to 
increase confidence in the AOO binaries and the AOO site as preferable for 
those downloads.  I think grabbing the low-hanging fruit and getting something 
simple through the process is also desirable, especially since we are starting 
from zero using the signing process.


-Original Message-
From: jan i [mailto:j...@apache.org] 
Sent: Tuesday, December 9, 2014 08:29
To: dev; Dennis Hamilton
Subject: Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)

On 9 December 2014 at 16:26, Dennis E. Hamilton 
wrote:

> Andrea,
>
[ ... ]
> (Or even sign the existing installer
> file, if it is in the proper format for inserting the information and
> signature.)  That is, the .cab, .msi, and setup.exe would be completely
> unchanged.
>
No we need to rebuild (and for every language), because the last step in
the build process needs to be repeated, we cannot just patch the files.

If we could move away from 1 install set pr language, the job would be
about 30 times faster :-)




AOO is special compared to most other projects, in that the majority of our
users use the binary package. As a consequence, I recommend a PMC vote,
even if its not strictly needed.

[ ... ]

>
> It would still have to be project-managed in the sense that all of the
> measures to preserve binary authenticity and provide accompanying binary
> release management internal to AOO should be followed.
>
[ ... ]


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

Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)

[Rob Weir]

On Tue, Dec 9, 2014 at 3:21 PM, jan i  wrote:
> On Tuesday, December 9, 2014, Rob Weir  wrote:
>
>> On Mon, Dec 8, 2014 at 9:29 PM, Dennis E. Hamilton
>> > wrote:
>> > I don't know if this is helpful or not.  I'm not in a position to check.
>> >
>> > Thinking out loud:
>> >
>> > There are two cases of signatures.
>> >
>> >  1. Digital signing of installable components, such as DLLs and such.
>> This is also important but a second-order problem.
>> >
>> >  2. Digital signing of the installer binary (the .EXE).  That or
>> shipping a signed .MSI.
>> > This is more important.  It has to do with raising the confidence in
>> downloads and installs and is of immediate benefit.
>> >
>> > It *may* be the case that the installer binary .EXE already has room in
>> the file for a signature and it is simply not being used.  The properties
>> on the binary .EXE are also not filled in for AOO 4.1.1 en-US.  Those are
>> the ones that show a File description, File version, Product name, Product
>> version, Copyright, Language, etc.
>> >
>> > It might be worthwhile to see if the properties and signature can be
>> injected in the .EXE already.  And if not, it may be possible to rebuild
>> the .EXE, since the bits are still around.  They are what are extracted
>> into a folder which is then used for running setup.
>> >
>> > If feasible, this strikes me as a perfectly worthwhile exercise for
>> slip-streaming a signed binary of AOO 4.1.1 for Windows.  As Andrea
>> remarks, It would also be a right-sized teething exercise for our learning
>> how to work through the signing process.
>> >
>>
>> I'm rather pessimistic.
>>
>> Here's what I see as the main user annoyances related the integrity of
>> AOO downloads:
>>
>> 1) Scams that ask for payment and then redirect to genuine versions of
>> AOO.   So the user has lost before they even download a single byte of
>> our package.   Signing will not help them,
>>
>> 2) Scams that wrap AOO's installer with an "installer" or similar app
>> that takes the user through a complicated set of screens to accept
>> various "offers" that result in adware/malware/badware being
>> installed.  Only then does it chain to the genuine AOO install.
>> Again, signing doesn't help the user.
>
>
> as long as we don't have a signed installer  nobody can tell the
> difference, but with a signed installer we would have a harder argument
> (agreed if people listen) ?
>

Not really.  In the above cases the damage is done*before* the user
ever launches our installer.  So in these cases whether it is signed
or not doesn't matter.


>>
>> 3) Download pages that offer genuine AOO downloads, but the page is
>> filled with other advertisements that lure the user into clicking
>> them, some which even claim they are the AOO download.  Signing
>> doesn't help the user much here.
>>
>> Note that in all of these cases, the bad code, the installer/wrapper
>> code could have a digital signature as well.  So user education --
>> don't run unsigned code -- doesn't really solve the problem here as
>> well.
>>
>> 4)   Annoyance of users who download genuine AOO from our website and
>> need to deal with extra mouse clicks to dismiss warning dialogs from
>> the browser, OS, antivirus, etc.   This is the main thing signing
>> fixes.
>>
>> This is worth doing, I think, for benefit #4.   But by itself it
>> doesn't really drain the swamp.  Note in particular that I have not
>> seen someone actually modify the AOO code or installer to make
>> malware.   Signing would help with that, if it happened.  But today
>> there are far easier scams.
>
>
> I agree with what you write, but I think you bypass a important point.
> Everybody tells now more than ever that we are dead...which is by far
> not true, and making a real volunteer release would show that clearly. (I
> appreciate what the paid developer do, so please don't be offended).
>
> To me digital signing is a nice way to show our community and users that
> AOO is still a major factor in this part of the world.
>

I'm not arguing against a release or against signing.   I'm just
pointing out that the scammers are two steps ahead of us, and even
with signing most of the problems still remain.

Regards,

-Rob


>
>
>
>> Regards,
>>
>> -Rob
>>
>>
>>
>>
>>
>>
>> > I'm all for starting with the least that 

Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)

[jan i]

On Tuesday, December 9, 2014, Rob Weir  wrote:

> On Mon, Dec 8, 2014 at 9:29 PM, Dennis E. Hamilton
> > wrote:
> > I don't know if this is helpful or not.  I'm not in a position to check.
> >
> > Thinking out loud:
> >
> > There are two cases of signatures.
> >
> >  1. Digital signing of installable components, such as DLLs and such.
> This is also important but a second-order problem.
> >
> >  2. Digital signing of the installer binary (the .EXE).  That or
> shipping a signed .MSI.
> > This is more important.  It has to do with raising the confidence in
> downloads and installs and is of immediate benefit.
> >
> > It *may* be the case that the installer binary .EXE already has room in
> the file for a signature and it is simply not being used.  The properties
> on the binary .EXE are also not filled in for AOO 4.1.1 en-US.  Those are
> the ones that show a File description, File version, Product name, Product
> version, Copyright, Language, etc.
> >
> > It might be worthwhile to see if the properties and signature can be
> injected in the .EXE already.  And if not, it may be possible to rebuild
> the .EXE, since the bits are still around.  They are what are extracted
> into a folder which is then used for running setup.
> >
> > If feasible, this strikes me as a perfectly worthwhile exercise for
> slip-streaming a signed binary of AOO 4.1.1 for Windows.  As Andrea
> remarks, It would also be a right-sized teething exercise for our learning
> how to work through the signing process.
> >
>
> I'm rather pessimistic.
>
> Here's what I see as the main user annoyances related the integrity of
> AOO downloads:
>
> 1) Scams that ask for payment and then redirect to genuine versions of
> AOO.   So the user has lost before they even download a single byte of
> our package.   Signing will not help them,
>
> 2) Scams that wrap AOO's installer with an "installer" or similar app
> that takes the user through a complicated set of screens to accept
> various "offers" that result in adware/malware/badware being
> installed.  Only then does it chain to the genuine AOO install.
> Again, signing doesn't help the user.


as long as we don't have a signed installer  nobody can tell the
difference, but with a signed installer we would have a harder argument
(agreed if people listen) ?

>
> 3) Download pages that offer genuine AOO downloads, but the page is
> filled with other advertisements that lure the user into clicking
> them, some which even claim they are the AOO download.  Signing
> doesn't help the user much here.
>
> Note that in all of these cases, the bad code, the installer/wrapper
> code could have a digital signature as well.  So user education --
> don't run unsigned code -- doesn't really solve the problem here as
> well.
>
> 4)   Annoyance of users who download genuine AOO from our website and
> need to deal with extra mouse clicks to dismiss warning dialogs from
> the browser, OS, antivirus, etc.   This is the main thing signing
> fixes.
>
> This is worth doing, I think, for benefit #4.   But by itself it
> doesn't really drain the swamp.  Note in particular that I have not
> seen someone actually modify the AOO code or installer to make
> malware.   Signing would help with that, if it happened.  But today
> there are far easier scams.


I agree with what you write, but I think you bypass a important point.
Everybody tells now more than ever that we are dead...which is by far
not true, and making a real volunteer release would show that clearly. (I
appreciate what the paid developer do, so please don't be offended).

To me digital signing is a nice way to show our community and users that
AOO is still a major factor in this part of the world.




> Regards,
>
> -Rob
>
>
>
>
>
>
> > I'm all for starting with the least that could possibly work, even
> though I have no expertise on this.
> >
> >  - Dennis
> >
> > -Original Message-
> > From: Andrea Pescetti [mailto:pesce...@apache.org ]
> > Sent: Monday, December 8, 2014 15:08
> > To: dev@openoffice.apache.org 
> > Subject: Re: Budapest and thereafter.
> >
> > Marcus wrote:
> >> Am 12/08/2014 02:32 PM, schrieb Andrea Pescetti:
> >>> We could actually do both, if you believe it makes sense:
> >>> - signed 4.1.1 (next Windows binaries only) by end of December
> >>> - 4.1.2 in January
> >> IMHO this doesn't make sense and would be just a waste of resources,
> >> when doing 2 releases in such a short time frame.
> >> But I would tend to do only the

Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)

[Rob Weir]

On Mon, Dec 8, 2014 at 9:29 PM, Dennis E. Hamilton
 wrote:
> I don't know if this is helpful or not.  I'm not in a position to check.
>
> Thinking out loud:
>
> There are two cases of signatures.
>
>  1. Digital signing of installable components, such as DLLs and such.  This 
> is also important but a second-order problem.
>
>  2. Digital signing of the installer binary (the .EXE).  That or shipping a 
> signed .MSI.
> This is more important.  It has to do with raising the confidence in 
> downloads and installs and is of immediate benefit.
>
> It *may* be the case that the installer binary .EXE already has room in the 
> file for a signature and it is simply not being used.  The properties on the 
> binary .EXE are also not filled in for AOO 4.1.1 en-US.  Those are the ones 
> that show a File description, File version, Product name, Product version, 
> Copyright, Language, etc.
>
> It might be worthwhile to see if the properties and signature can be injected 
> in the .EXE already.  And if not, it may be possible to rebuild the .EXE, 
> since the bits are still around.  They are what are extracted into a folder 
> which is then used for running setup.
>
> If feasible, this strikes me as a perfectly worthwhile exercise for 
> slip-streaming a signed binary of AOO 4.1.1 for Windows.  As Andrea remarks, 
> It would also be a right-sized teething exercise for our learning how to work 
> through the signing process.
>

I'm rather pessimistic.

Here's what I see as the main user annoyances related the integrity of
AOO downloads:

1) Scams that ask for payment and then redirect to genuine versions of
AOO.   So the user has lost before they even download a single byte of
our package.   Signing will not help them,

2) Scams that wrap AOO's installer with an "installer" or similar app
that takes the user through a complicated set of screens to accept
various "offers" that result in adware/malware/badware being
installed.  Only then does it chain to the genuine AOO install.
Again, signing doesn't help the user.

3) Download pages that offer genuine AOO downloads, but the page is
filled with other advertisements that lure the user into clicking
them, some which even claim they are the AOO download.  Signing
doesn't help the user much here.

Note that in all of these cases, the bad code, the installer/wrapper
code could have a digital signature as well.  So user education --
don't run unsigned code -- doesn't really solve the problem here as
well.

4)   Annoyance of users who download genuine AOO from our website and
need to deal with extra mouse clicks to dismiss warning dialogs from
the browser, OS, antivirus, etc.   This is the main thing signing
fixes.

This is worth doing, I think, for benefit #4.   But by itself it
doesn't really drain the swamp.  Note in particular that I have not
seen someone actually modify the AOO code or installer to make
malware.   Signing would help with that, if it happened.  But today
there are far easier scams.

Regards,

-Rob






> I'm all for starting with the least that could possibly work, even though I 
> have no expertise on this.
>
>  - Dennis
>
> -Original Message-
> From: Andrea Pescetti [mailto:pesce...@apache.org]
> Sent: Monday, December 8, 2014 15:08
> To: dev@openoffice.apache.org
> Subject: Re: Budapest and thereafter.
>
> Marcus wrote:
>> Am 12/08/2014 02:32 PM, schrieb Andrea Pescetti:
>>> We could actually do both, if you believe it makes sense:
>>> - signed 4.1.1 (next Windows binaries only) by end of December
>>> - 4.1.2 in January
>> IMHO this doesn't make sense and would be just a waste of resources,
>> when doing 2 releases in such a short time frame.
>> But I would tend to do only the bigger release (4.1.2) - let's say in
>> January/February. When ...
>
> Honestly, Infra would like (and they are right) that after asking for
> years for digital signing, we actually use it. We can't put many
> obstacles in front of it. So a long list of things that we must have
> ready before that won't work. Signing Windows binaries will have to
> happen, and users will benefit from it in terms of trust in OpenOffice.
>
> Assuming that more or less we can master the technology, distributing
> the 4.1.1 signed binaries is not a huge feat for us (it would need
> production of the new binaries and their upload to a new directory like
> "windows-signed" and defaulting to "windows-signed" in the JavaScript in
> the download page). It is far less than a release and at least it could
> show that on this (new for OpenOffice) topic we are ready.
>
> In case I wasn't clear (and this is my fault for not summarizing the
> Budape

Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)

[jan i]

On 9 December 2014 at 16:26, Dennis E. Hamilton 
wrote:

> Andrea,
>
> Although I consider this very important, I am so far back the learning
> curve on working with the actual bits that I don't think I can provide
> anything competent in a short time.  If you think there is an useful way
> for me to move along the curve in time to be useful, I am open to it.
>
> One question, also for Jürgen and Jan.  Is it possible to enter the
> signing process for just the last step -- using the 4.1.1 setup files,
> which are easily available, and making an installer file with appropriate
> file properties and a signature?  (Or even sign the existing installer
> file, if it is in the proper format for inserting the information and
> signature.)  That is, the .cab, .msi, and setup.exe would be completely
> unchanged.
>
No we need to rebuild (and for every language), because the last step in
the build process needs to be repeated, we cannot just patch the files.

If we could move away from 1 install set pr language, the job would be
about 30 times faster :-)



>
> It is not the whole job, but it would make for an easy 4.1.1 slip-stream
> update and start solving one of the problems of being able to identify the
> origin of "courtesy" binaries that the project is willing to support.
>
> (There are loud reminders on other lists that courtesy binaries are not
> Apache capital-R Releases, only the sources are, so this would technically
> not involve a new AOO Project Release at all.  There should be absolutely
> no difference other than the installer is authenticated and makes Windows
> happier in itself, without worrying about Windows certification at this
> stage.)
>

AOO is special compared to most other projects, in that the majority of our
users use the binary package. As a consequence, I recommend a PMC vote,
even if its not strictly needed.

rgds
jan i.

>
> It would still have to be project-managed in the sense that all of the
> measures to preserve binary authenticity and provide accompanying binary
> release management internal to AOO should be followed.
>
> Still thinking out loud, wanting to be helpful.
>
>  - Dennis
>
> PS: Corinthia has to learn to do this anyhow, but that incubator has the
> advantage of not being under any time pressure and can provide signed
> binaries from the beginning, so teething and preserving the knowledge may
> be easier.
>
>
>
> -Original Message-
> From: Andrea Pescetti [mailto:pesce...@apache.org]
> Sent: Tuesday, December 9, 2014 00:17
> To: dev@openoffice.apache.org
> Subject: Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)
>
> Jürgen Schmidt wrote:
> > We had a signing mechanism in place for a long time and the reason why
> > we have currently no digital signing is the lack of a certificate where
> > we as project (PMC) or as representative the release manager have enough
> > control.
>
> I do have a certificate and access key to the signing service. Details
> in my "OpenOffice and Infra" report
> http://markmail.org/message/6ymi35tajswcfsps item 4.
>
> Of course, I'm more than happy if someone else is willing to help with
> this; maybe Jan's work of months ago can now be reused and we can sign
> with minimal effort.
>
> 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: Signing AOO 4.1.1 (was RE: Budapest and thereafter)

[Dennis E. Hamilton]

Andrea,

Although I consider this very important, I am so far back the learning curve on 
working with the actual bits that I don't think I can provide anything 
competent in a short time.  If you think there is an useful way for me to move 
along the curve in time to be useful, I am open to it.

One question, also for Jürgen and Jan.  Is it possible to enter the signing 
process for just the last step -- using the 4.1.1 setup files, which are easily 
available, and making an installer file with appropriate file properties and a 
signature?  (Or even sign the existing installer file, if it is in the proper 
format for inserting the information and signature.)  That is, the .cab, .msi, 
and setup.exe would be completely unchanged.

It is not the whole job, but it would make for an easy 4.1.1 slip-stream update 
and start solving one of the problems of being able to identify the origin of 
"courtesy" binaries that the project is willing to support.

(There are loud reminders on other lists that courtesy binaries are not Apache 
capital-R Releases, only the sources are, so this would technically not involve 
a new AOO Project Release at all.  There should be absolutely no difference 
other than the installer is authenticated and makes Windows happier in itself, 
without worrying about Windows certification at this stage.)

It would still have to be project-managed in the sense that all of the measures 
to preserve binary authenticity and provide accompanying binary release 
management internal to AOO should be followed.

Still thinking out loud, wanting to be helpful.

 - Dennis

PS: Corinthia has to learn to do this anyhow, but that incubator has the 
advantage of not being under any time pressure and can provide signed binaries 
from the beginning, so teething and preserving the knowledge may be easier.



-Original Message-
From: Andrea Pescetti [mailto:pesce...@apache.org] 
Sent: Tuesday, December 9, 2014 00:17
To: dev@openoffice.apache.org
Subject: Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)

Jürgen Schmidt wrote:
> We had a signing mechanism in place for a long time and the reason why
> we have currently no digital signing is the lack of a certificate where
> we as project (PMC) or as representative the release manager have enough
> control.

I do have a certificate and access key to the signing service. Details 
in my "OpenOffice and Infra" report 
http://markmail.org/message/6ymi35tajswcfsps item 4.

Of course, I'm more than happy if someone else is willing to help with 
this; maybe Jan's work of months ago can now be reused and we can sign 
with minimal effort.

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: Budapest and thereafter.

[jan i]

On Tuesday, December 9, 2014, Jürgen Schmidt  wrote:

> On 08/12/14 20:15, jan i wrote:
> > On 8 December 2014 at 19:50, Rory O'Farrell  > wrote:
> >
> >> On Mon, 08 Dec 2014 19:37:41 +0100
> >> Marcus > wrote:
> >>
> >>> Am 12/08/2014 06:31 PM, schrieb Rory O'Farrell:
>  On Mon, 8 Dec 2014 09:19:17 -0800
>  Kay Schenk>  wrote:
> 
> > And, I didn't review the infra ticket on Cent OS carefully. Until we
> >> make a
> > decision that we do not want to provide Linux-32 binaries, we need a
> >> 32-bit
> > Cent OS 5 buildbot.  I'' create a new ticket today.
> 
>  Possibly because most OO developers have 64 bit computers, we tend to
> >>>  > overlook the need for 32 bit versions of OO. We should not lose
> sight
> >>>  > of the need for such versions - it as a way of introducing people
> >>>  > using older machines.  Most of the older people I know (mostly 65+,
> >>>  > retired) are using 32 bit machines, often handed down from their
> >>>  > children.
> >>>
> >>> right, but do you really mean - or have heard/read - that they get
> Linux
> >>> machines from their children? I think it will be still Windows - and
> >>> here 32 or 64 bit doesn't matter.
> >>>
> >>> But anyway, yes we still need 32-bit binaries for Linux.
> >>>
> >>> Marcus
> >>>
> >> When I am asked I guide them to 32 bit linux to help older computers
> work
> >> well. If we drop 32 bit for linux, we effectively abandon that area to
> >> LibO; we have enough of an uphill fight regaining users from the inbuilt
> >> installation of LibO on the distros as it is.  We shouldn't abandon that
> >> area.
> >>
> >
> > I dont follow the notion of "abandon that area", we have never had a
> 32bit
> > centOS buildbot or for that matter a 64bit, so we are not abandoning
> > anything, we are instead expanding.
> >
> > I dont know if we made releases available on centOS earlier, but for sure
> > we did not do it with ASF buildbot.
>
> sure all our past releases were built on Centos machines (32 and 64
> bit). This was discussed very often and the reason is that we need a
> certain baseline that our binaries run on as much as possible distros.
> You know we are not in the comfortable situation that the distros built
> AOO specific for their baseline and include it by default.
>
> The ASF build bots are running on Linux systems that are simply to new.
> Another option would be to increase the baseline and drop 32 bit Linux
> completely. This would reduce the effort enormous but I am not sure it
> is what we want.
>
> This baseline discussion might be difficult to understand for ASF infra
> people who are building everything from scratch. But the OpenOffice
> users are different and expecting simply a binary that they can install
> and use.

No its nof difficult to understand, but expecting those things to happen
without requesting it will not work.

E.g. the mac buildbot is solely for aoo so we could easy add 1-2 vm and
thereby have the different mac versions covered.

The idea with tethys (a physical machine) was the same, have e.g. ubuntu in
the bottom and then specific vms for all intel based builds (that is my
personal setup and works brilliantly).

So the problem does not really boil down to infra not understanding. but a
lot more that nobody in aoo (or at least so it seems) are willing to do the
job (or if willing does not get shot down).

just my pow, being one with a leg in both projects.

rgds
jan i

>
>
> Juergen
>
> >
> > rgds
> > jan i
> >
> >
> >>
> >> --
> >> Rory O'Farrell >
> >>
> >> -
> >> 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
> 
>
>

-- 
Sent from My iPad, sorry for any misspellings.

Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)

[jan i]

On Tuesday, December 9, 2014, Jürgen Schmidt  wrote:

> On 09/12/14 09:17, Andrea Pescetti wrote:
> > Jürgen Schmidt wrote:
> >> We had a signing mechanism in place for a long time and the reason why
> >> we have currently no digital signing is the lack of a certificate where
> >> we as project (PMC) or as representative the release manager have enough
> >> control.
> >
> > I do have a certificate and access key to the signing service. Details
> > in my "OpenOffice and Infra" report
> > http://markmail.org/message/6ymi35tajswcfsps item 4.
> >
> > Of course, I'm more than happy if someone else is willing to help with
> > this; maybe Jan's work of months ago can now be reused and we can sign
> > with minimal effort.
>
> I don't have time to do it but I would start with analyzing which parts
> have to be signed. The former process signed all binary artifacts (dll,
> jars, .NET assemblies, ...). I am not sure if this is all necessary or
> if it was just signed for simplification.
>
> The new mechanism requires a more or less rework of the signing process.
> And it will result probably in a multiphase signing and packaging
> process. First round is to sign exe, dlls, assemblies etc. figured out
> in the initial analysis. Second step is to package the msi and the
> setup.exe. And finally package the downloadable exe and sign this as well.
>
> Of course anybody can do the investigation again, but the rule is quite
clear. Windows loadable components must be signed, in our case jar, dll and
exe.

I did not change a bit in the build system for my test, but had
simple one-liner scrips to help.

First script runs through all release languages, run configure and make.
then renames the output dir with dll etc. (it also renamed the dll,jar to
xyz.lang.dll)

Second step was manual, upload  to symantic gui and sign, download the
signed artifacts

Second script runs through all release languages, renames the output dir
back, runs configure and then make postprocess. Finally it renames the
install set.

Last step was manual, upload all instlallers to symantic, sign and download.


we (infra) spent quite sometime discussing a local solution, but it turned
out to be vey costly (both in terms of real money and man hours). We then
say that symantic actually provide at least 80% of the solution we looked
at, so the choice was simple.

rgds
jan i

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

-- 
Sent from My iPad, sorry for any misspellings.

Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)

[Jürgen Schmidt]

On 09/12/14 09:17, Andrea Pescetti wrote:
> Jürgen Schmidt wrote:
>> We had a signing mechanism in place for a long time and the reason why
>> we have currently no digital signing is the lack of a certificate where
>> we as project (PMC) or as representative the release manager have enough
>> control.
> 
> I do have a certificate and access key to the signing service. Details
> in my "OpenOffice and Infra" report
> http://markmail.org/message/6ymi35tajswcfsps item 4.
> 
> Of course, I'm more than happy if someone else is willing to help with
> this; maybe Jan's work of months ago can now be reused and we can sign
> with minimal effort.

I don't have time to do it but I would start with analyzing which parts
have to be signed. The former process signed all binary artifacts (dll,
jars, .NET assemblies, ...). I am not sure if this is all necessary or
if it was just signed for simplification.

The new mechanism requires a more or less rework of the signing process.
And it will result probably in a multiphase signing and packaging
process. First round is to sign exe, dlls, assemblies etc. figured out
in the initial analysis. Second step is to package the msi and the
setup.exe. And finally package the downloadable exe and sign this as well.

Juergen

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

Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)

[Andrea Pescetti]

Jürgen Schmidt wrote:

We had a signing mechanism in place for a long time and the reason why
we have currently no digital signing is the lack of a certificate where
we as project (PMC) or as representative the release manager have enough
control.


I do have a certificate and access key to the signing service. Details 
in my "OpenOffice and Infra" report 
http://markmail.org/message/6ymi35tajswcfsps item 4.


Of course, I'm more than happy if someone else is willing to help with 
this; maybe Jan's work of months ago can now be reused and we can sign 
with minimal effort.


Regards,
  Andrea.

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

Re: Budapest and thereafter.

[Jürgen Schmidt]

On 08/12/14 20:15, jan i wrote:
> On 8 December 2014 at 19:50, Rory O'Farrell  wrote:
> 
>> On Mon, 08 Dec 2014 19:37:41 +0100
>> Marcus  wrote:
>>
>>> Am 12/08/2014 06:31 PM, schrieb Rory O'Farrell:
 On Mon, 8 Dec 2014 09:19:17 -0800
 Kay Schenk  wrote:

> And, I didn't review the infra ticket on Cent OS carefully. Until we
>> make a
> decision that we do not want to provide Linux-32 binaries, we need a
>> 32-bit
> Cent OS 5 buildbot.  I'' create a new ticket today.

 Possibly because most OO developers have 64 bit computers, we tend to
>>>  > overlook the need for 32 bit versions of OO. We should not lose sight
>>>  > of the need for such versions - it as a way of introducing people
>>>  > using older machines.  Most of the older people I know (mostly 65+,
>>>  > retired) are using 32 bit machines, often handed down from their
>>>  > children.
>>>
>>> right, but do you really mean - or have heard/read - that they get Linux
>>> machines from their children? I think it will be still Windows - and
>>> here 32 or 64 bit doesn't matter.
>>>
>>> But anyway, yes we still need 32-bit binaries for Linux.
>>>
>>> Marcus
>>>
>> When I am asked I guide them to 32 bit linux to help older computers work
>> well. If we drop 32 bit for linux, we effectively abandon that area to
>> LibO; we have enough of an uphill fight regaining users from the inbuilt
>> installation of LibO on the distros as it is.  We shouldn't abandon that
>> area.
>>
> 
> I dont follow the notion of "abandon that area", we have never had a 32bit
> centOS buildbot or for that matter a 64bit, so we are not abandoning
> anything, we are instead expanding.
> 
> I dont know if we made releases available on centOS earlier, but for sure
> we did not do it with ASF buildbot.

sure all our past releases were built on Centos machines (32 and 64
bit). This was discussed very often and the reason is that we need a
certain baseline that our binaries run on as much as possible distros.
You know we are not in the comfortable situation that the distros built
AOO specific for their baseline and include it by default.

The ASF build bots are running on Linux systems that are simply to new.
Another option would be to increase the baseline and drop 32 bit Linux
completely. This would reduce the effort enormous but I am not sure it
is what we want.

This baseline discussion might be difficult to understand for ASF infra
people who are building everything from scratch. But the OpenOffice
users are different and expecting simply a binary that they can install
and use.


Juergen

> 
> rgds
> jan i
> 
> 
>>
>> --
>> Rory O'Farrell 
>>
>> -
>> 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: Signing AOO 4.1.1 (was RE: Budapest and thereafter)

[Jürgen Schmidt]

On 09/12/14 03:29, Dennis E. Hamilton wrote:
> I don't know if this is helpful or not.  I'm not in a position to check.
> 
> Thinking out loud:
> 
> There are two cases of signatures.
> 
>  1. Digital signing of installable components, such as DLLs and such.  This 
> is also important but a second-order problem.
> 
>  2. Digital signing of the installer binary (the .EXE).  That or shipping a 
> signed .MSI.
> This is more important.  It has to do with raising the confidence in 
> downloads and installs and is of immediate benefit.  
> 
> It *may* be the case that the installer binary .EXE already has room in the 
> file for a signature and it is simply not being used.  The properties on the 
> binary .EXE are also not filled in for AOO 4.1.1 en-US.  Those are the ones 
> that show a File description, File version, Product name, Product version, 
> Copyright, Language, etc. 
> 
> It might be worthwhile to see if the properties and signature can be injected 
> in the .EXE already.  And if not, it may be possible to rebuild the .EXE, 
> since the bits are still around.  They are what are extracted into a folder 
> which is then used for running setup.
> 
> If feasible, this strikes me as a perfectly worthwhile exercise for 
> slip-streaming a signed binary of AOO 4.1.1 for Windows.  As Andrea remarks, 
> It would also be a right-sized teething exercise for our learning how to work 
> through the signing process.
> 
> I'm all for starting with the least that could possibly work, even though I 
> have no expertise on this.

We had a signing mechanism in place for a long time and the reason why
we have currently no digital signing is the lack of a certificate where
we as project (PMC) or as representative the release manager have enough
control.

Anyway the new process should be used to sign the libs and other binary
artifacts inside the install set and the installer binary itself.

All this should be designed that it works more or less automatic or semi
automatic using the new process. I hope the new signing mechanism can be
used in a proper and efficient way for AOO.

I am still no friend of this new process because we shift many many bits
over the network and a local signing process on a dedicated machine
looks more efficient and easier to me. But it is as it is and not under
my control.

Juergen



> 
>  - Dennis
> 
> -Original Message-
> From: Andrea Pescetti [mailto:pesce...@apache.org] 
> Sent: Monday, December 8, 2014 15:08
> To: dev@openoffice.apache.org
> Subject: Re: Budapest and thereafter.
> 
> Marcus wrote:
>> Am 12/08/2014 02:32 PM, schrieb Andrea Pescetti:
>>> We could actually do both, if you believe it makes sense:
>>> - signed 4.1.1 (next Windows binaries only) by end of December
>>> - 4.1.2 in January
>> IMHO this doesn't make sense and would be just a waste of resources,
>> when doing 2 releases in such a short time frame.
>> But I would tend to do only the bigger release (4.1.2) - let's say in
>> January/February. When ...
> 
> Honestly, Infra would like (and they are right) that after asking for 
> years for digital signing, we actually use it. We can't put many 
> obstacles in front of it. So a long list of things that we must have 
> ready before that won't work. Signing Windows binaries will have to 
> happen, and users will benefit from it in terms of trust in OpenOffice.
> 
> Assuming that more or less we can master the technology, distributing 
> the 4.1.1 signed binaries is not a huge feat for us (it would need 
> production of the new binaries and their upload to a new directory like 
> "windows-signed" and defaulting to "windows-signed" in the JavaScript in 
> the download page). It is far less than a release and at least it could 
> show that on this (new for OpenOffice) topic we are ready.
> 
> In case I wasn't clear (and this is my fault for not summarizing the 
> Budapest talks correctly) signed binaries have high priority. One way is 
> to make a 4.1.2 release and sign it, and this requires going through the 
> whole process (no, it can't be a Windows-only release). Another way is 
> to ship a signed version of the existing 4.1.1 binaries as a "warm up" 
> for the moment when this will be integral part of the release process.
> 
> 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
> 


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

Signing AOO 4.1.1 (was RE: Budapest and thereafter)

[Dennis E. Hamilton]

I don't know if this is helpful or not.  I'm not in a position to check.

Thinking out loud:

There are two cases of signatures.

 1. Digital signing of installable components, such as DLLs and such.  This is 
also important but a second-order problem.

 2. Digital signing of the installer binary (the .EXE).  That or shipping a 
signed .MSI.
This is more important.  It has to do with raising the confidence in 
downloads and installs and is of immediate benefit.  

It *may* be the case that the installer binary .EXE already has room in the 
file for a signature and it is simply not being used.  The properties on the 
binary .EXE are also not filled in for AOO 4.1.1 en-US.  Those are the ones 
that show a File description, File version, Product name, Product version, 
Copyright, Language, etc. 

It might be worthwhile to see if the properties and signature can be injected 
in the .EXE already.  And if not, it may be possible to rebuild the .EXE, since 
the bits are still around.  They are what are extracted into a folder which is 
then used for running setup.

If feasible, this strikes me as a perfectly worthwhile exercise for 
slip-streaming a signed binary of AOO 4.1.1 for Windows.  As Andrea remarks, It 
would also be a right-sized teething exercise for our learning how to work 
through the signing process.

I'm all for starting with the least that could possibly work, even though I 
have no expertise on this.

 - Dennis

-Original Message-
From: Andrea Pescetti [mailto:pesce...@apache.org] 
Sent: Monday, December 8, 2014 15:08
To: dev@openoffice.apache.org
Subject: Re: Budapest and thereafter.

Marcus wrote:
> Am 12/08/2014 02:32 PM, schrieb Andrea Pescetti:
>> We could actually do both, if you believe it makes sense:
>> - signed 4.1.1 (next Windows binaries only) by end of December
>> - 4.1.2 in January
> IMHO this doesn't make sense and would be just a waste of resources,
> when doing 2 releases in such a short time frame.
> But I would tend to do only the bigger release (4.1.2) - let's say in
> January/February. When ...

Honestly, Infra would like (and they are right) that after asking for 
years for digital signing, we actually use it. We can't put many 
obstacles in front of it. So a long list of things that we must have 
ready before that won't work. Signing Windows binaries will have to 
happen, and users will benefit from it in terms of trust in OpenOffice.

Assuming that more or less we can master the technology, distributing 
the 4.1.1 signed binaries is not a huge feat for us (it would need 
production of the new binaries and their upload to a new directory like 
"windows-signed" and defaulting to "windows-signed" in the JavaScript in 
the download page). It is far less than a release and at least it could 
show that on this (new for OpenOffice) topic we are ready.

In case I wasn't clear (and this is my fault for not summarizing the 
Budapest talks correctly) signed binaries have high priority. One way is 
to make a 4.1.2 release and sign it, and this requires going through the 
whole process (no, it can't be a Windows-only release). Another way is 
to ship a signed version of the existing 4.1.1 binaries as a "warm up" 
for the moment when this will be integral part of the release process.

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: Budapest and thereafter.

[Marcus]

Am 12/08/2014 08:30 PM, schrieb jan i:

On 8 December 2014 at 20:15, jan i  wrote:


On 8 December 2014 at 19:50, Rory O'Farrell  wrote:


On Mon, 08 Dec 2014 19:37:41 +0100
Marcus  wrote:


Am 12/08/2014 06:31 PM, schrieb Rory O'Farrell:

On Mon, 8 Dec 2014 09:19:17 -0800
Kay Schenk   wrote:


And, I didn't review the infra ticket on Cent OS carefully. Until we

make a

decision that we do not want to provide Linux-32 binaries, we need a

32-bit

Cent OS 5 buildbot.  I'' create a new ticket today.


Possibly because most OO developers have 64 bit computers, we tend to

  >  overlook the need for 32 bit versions of OO. We should not lose sight
  >  of the need for such versions - it as a way of introducing people
  >  using older machines.  Most of the older people I know (mostly 65+,
  >  retired) are using 32 bit machines, often handed down from their
  >  children.

right, but do you really mean - or have heard/read - that they get Linux
machines from their children? I think it will be still Windows - and
here 32 or 64 bit doesn't matter.

But anyway, yes we still need 32-bit binaries for Linux.

Marcus


When I am asked I guide them to 32 bit linux to help older computers work
well. If we drop 32 bit for linux, we effectively abandon that area to
LibO; we have enough of an uphill fight regaining users from the inbuilt
installation of LibO on the distros as it is.  We shouldn't abandon that
area.



I dont follow the notion of "abandon that area", we have never had a 32bit
centOS buildbot or for that matter a 64bit, so we are not abandoning
anything, we are instead expanding.

I dont know if we made releases available on centOS earlier, but for sure
we did not do it with ASF buildbot.

rgds
jan i




And a addon to the general discussion, if I may bring it down to something
we can handle again.

We can wish anything (especially around christmas), but fact is:
- We have tried to change the ASF buildbots used, to generate releases (the
configure options are set differently) for as long as we have been a TLP.
- We have had a MAC buildbot for several month now, and its still not
production
- Last time (about 6month ago) when infra (in person me) rolled a centOS vm
for buildbot, the interest was less the time it cost to write a mail so in
fact it was abendoned.
- There are no (and as far as I can see have been no) jira for a 32bit
centOS.
- Currently we have no release manager, and as far as I know nobody have
asked to become a release manager.

So may I politely ask, what have changed, that we now believe this will all
go away, and we can have it all solved in a short time ?

To me the above points are months of work, until tested and stable, and
considering we havent even started, I think it is fair to ask, do we really
want to wait until this magically happens ?

Sorry for being very direct (its my danish style), but we need to get


don't worry about your style, I can understand this.


things moving instead of just dreaming...so who will take care of which of
the above points ?


To answer this also directly:

- As I haven't the techincal understanding of buildbots I cannot help here.

- And for the release manager hat on, puh, I think you need much more 
time than just 2-3 hours per day - which are not in your evening hours. 
So, also here a sorry from me.


Marcus

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

Re: Budapest and thereafter.

[Marcus]

Am 12/09/2014 12:07 AM, schrieb Andrea Pescetti:

Marcus wrote:

Am 12/08/2014 02:32 PM, schrieb Andrea Pescetti:

We could actually do both, if you believe it makes sense:
- signed 4.1.1 (next Windows binaries only) by end of December
- 4.1.2 in January

IMHO this doesn't make sense and would be just a waste of resources,
when doing 2 releases in such a short time frame.
But I would tend to do only the bigger release (4.1.2) - let's say in
January/February. When ...


Honestly, Infra would like (and they are right) that after asking for
years for digital signing, we actually use it. We can't put many
obstacles in front of it. So a long list of things that we must have
ready before that won't work. Signing Windows binaries will have to
happen, and users will benefit from it in terms of trust in OpenOffice.

Assuming that more or less we can master the technology, distributing
the 4.1.1 signed binaries is not a huge feat for us (it would need
production of the new binaries and their upload to a new directory like
"windows-signed" and defaulting to "windows-signed" in the JavaScript in
the download page). It is far less than a release and at least it could
show that on this (new for OpenOffice) topic we are ready.

In case I wasn't clear (and this is my fault for not summarizing the
Budapest talks correctly) signed binaries have high priority. One way is
to make a 4.1.2 release and sign it, and this requires going through the
whole process (no, it can't be a Windows-only release). Another way is
to ship a signed version of the existing 4.1.1 binaries as a "warm up"
for the moment when this will be integral part of the release process.


all nice words. But it doesn't matter and especially for the Windows 
build it's indeed not a long list of obstacles, wishes, or what ever. 
Just one: Who will - and can - do it?


So, when we have answered this question, we are a big step towards a new 
release.


Marcus


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

Re: Budapest and thereafter.

[Kay Schenk]

On Mon, Dec 8, 2014 at 11:30 AM, jan i  wrote:

> On 8 December 2014 at 20:15, jan i  wrote:
>
> >
> >
> >
> >
> > On 8 December 2014 at 19:50, Rory O'Farrell  wrote:
> >
> >> On Mon, 08 Dec 2014 19:37:41 +0100
> >> Marcus  wrote:
> >>
> >> > Am 12/08/2014 06:31 PM, schrieb Rory O'Farrell:
> >> > > On Mon, 8 Dec 2014 09:19:17 -0800
> >> > > Kay Schenk  wrote:
> >> > >
> >> > >> And, I didn't review the infra ticket on Cent OS carefully. Until
> we
> >> make a
> >> > >> decision that we do not want to provide Linux-32 binaries, we need
> a
> >> 32-bit
> >> > >> Cent OS 5 buildbot.  I'' create a new ticket today.
> >> > >
> >> > > Possibly because most OO developers have 64 bit computers, we tend
> to
> >> >  > overlook the need for 32 bit versions of OO. We should not lose
> sight
> >> >  > of the need for such versions - it as a way of introducing people
> >> >  > using older machines.  Most of the older people I know (mostly 65+,
> >> >  > retired) are using 32 bit machines, often handed down from their
> >> >  > children.
> >> >
> >> > right, but do you really mean - or have heard/read - that they get
> Linux
> >> > machines from their children? I think it will be still Windows - and
> >> > here 32 or 64 bit doesn't matter.
> >> >
> >> > But anyway, yes we still need 32-bit binaries for Linux.
> >> >
> >> > Marcus
> >> >
> >> When I am asked I guide them to 32 bit linux to help older computers
> work
> >> well. If we drop 32 bit for linux, we effectively abandon that area to
> >> LibO; we have enough of an uphill fight regaining users from the inbuilt
> >> installation of LibO on the distros as it is.  We shouldn't abandon that
> >> area.
> >>
> >
> > I dont follow the notion of "abandon that area", we have never had a
> 32bit
> > centOS buildbot or for that matter a 64bit, so we are not abandoning
> > anything, we are instead expanding.
> >
> > I dont know if we made releases available on centOS earlier, but for sure
> > we did not do it with ASF buildbot.
> >
> > rgds
> > jan i
> >
>
>
> And a addon to the general discussion, if I may bring it down to something
> we can handle again.
>
> We can wish anything (especially around christmas), but fact is:
> - We have tried to change the ASF buildbots used, to generate releases (the
> configure options are set differently) for as long as we have been a TLP.
>

I didn't realize the config options were different. OK, good to know. I
thought the config options used for the buildbots were the defaults for
some reason. Ok, we need to double check this with Juergen who has been
spinning the distributed binaries.


> - We have had a MAC buildbot for several month now, and its still not
> production
> - Last time (about 6month ago) when infra (in person me) rolled a centOS vm
> for buildbot, the interest was less the time it cost to write a mail so in
> fact it was abendoned.
> - There are no (and as far as I can see have been no) jira for a 32bit
> centOS.
>

please see jira ticket -- 6217

 https://issues.apache.org/jira/browse/INFRA-6217

This was originally for 32-bit

So 

- Currently we have no release manager, and as far as I know nobody have
> asked to become a release manager.
>
> So may I politely ask, what have changed, that we now believe this will all
> go away, and we can have it all solved in a short time ?
>
> To me the above points are months of work, until tested and stable, and
> considering we havent even started, I think it is fair to ask, do we really
> want to wait until this magically happens ?
>

I agree completely with this assessment.

What are the alternatives to not waiting? I don't see that we have any
currently.


>
> Sorry for being very direct (its my danish style), but we need to get
> things moving instead of just dreaming...so who will take care of which of
> the above points ?
>
> I will make sure (with my infra hat on), that when the centOS (64bit) is
> needed, (meaning somebody will actually care for it, after having cared for
> the MAC buildbot, which Infra spent money on), then it will be there.
>

Super! We need this!


>
> rgds
> jan i.
>
> >
> >
> >>
> >> --
> >> Rory O'Farrell 
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>
> >>
> >
>



-- 
-
MzK

"There's a bit of magic in everything,
  and some loss to even things out."
-- Lou Reed

Re: Budapest and thereafter.

[Andrea Pescetti]

Marcus wrote:

Am 12/08/2014 02:32 PM, schrieb Andrea Pescetti:

We could actually do both, if you believe it makes sense:
- signed 4.1.1 (next Windows binaries only) by end of December
- 4.1.2 in January

IMHO this doesn't make sense and would be just a waste of resources,
when doing 2 releases in such a short time frame.
But I would tend to do only the bigger release (4.1.2) - let's say in
January/February. When ...


Honestly, Infra would like (and they are right) that after asking for 
years for digital signing, we actually use it. We can't put many 
obstacles in front of it. So a long list of things that we must have 
ready before that won't work. Signing Windows binaries will have to 
happen, and users will benefit from it in terms of trust in OpenOffice.


Assuming that more or less we can master the technology, distributing 
the 4.1.1 signed binaries is not a huge feat for us (it would need 
production of the new binaries and their upload to a new directory like 
"windows-signed" and defaulting to "windows-signed" in the JavaScript in 
the download page). It is far less than a release and at least it could 
show that on this (new for OpenOffice) topic we are ready.


In case I wasn't clear (and this is my fault for not summarizing the 
Budapest talks correctly) signed binaries have high priority. One way is 
to make a 4.1.2 release and sign it, and this requires going through the 
whole process (no, it can't be a Windows-only release). Another way is 
to ship a signed version of the existing 4.1.1 binaries as a "warm up" 
for the moment when this will be integral part of the release process.


Regards,
  Andrea.

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

Re: Budapest and thereafter.

[Regina Henschel]

Hi Jan,

jan i schrieb:

[..]



Sorry for being very direct (its my danish style), but we need to get
things moving instead of just dreaming...so who will take care of which of
the above points ?


I have been silent, because I'm not able to do any of that points.

Kind regards
Regina


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

Re: Budapest and thereafter.

[jan i]

On 8 December 2014 at 20:15, jan i  wrote:

>
>
>
>
> On 8 December 2014 at 19:50, Rory O'Farrell  wrote:
>
>> On Mon, 08 Dec 2014 19:37:41 +0100
>> Marcus  wrote:
>>
>> > Am 12/08/2014 06:31 PM, schrieb Rory O'Farrell:
>> > > On Mon, 8 Dec 2014 09:19:17 -0800
>> > > Kay Schenk  wrote:
>> > >
>> > >> And, I didn't review the infra ticket on Cent OS carefully. Until we
>> make a
>> > >> decision that we do not want to provide Linux-32 binaries, we need a
>> 32-bit
>> > >> Cent OS 5 buildbot.  I'' create a new ticket today.
>> > >
>> > > Possibly because most OO developers have 64 bit computers, we tend to
>> >  > overlook the need for 32 bit versions of OO. We should not lose sight
>> >  > of the need for such versions - it as a way of introducing people
>> >  > using older machines.  Most of the older people I know (mostly 65+,
>> >  > retired) are using 32 bit machines, often handed down from their
>> >  > children.
>> >
>> > right, but do you really mean - or have heard/read - that they get Linux
>> > machines from their children? I think it will be still Windows - and
>> > here 32 or 64 bit doesn't matter.
>> >
>> > But anyway, yes we still need 32-bit binaries for Linux.
>> >
>> > Marcus
>> >
>> When I am asked I guide them to 32 bit linux to help older computers work
>> well. If we drop 32 bit for linux, we effectively abandon that area to
>> LibO; we have enough of an uphill fight regaining users from the inbuilt
>> installation of LibO on the distros as it is.  We shouldn't abandon that
>> area.
>>
>
> I dont follow the notion of "abandon that area", we have never had a 32bit
> centOS buildbot or for that matter a 64bit, so we are not abandoning
> anything, we are instead expanding.
>
> I dont know if we made releases available on centOS earlier, but for sure
> we did not do it with ASF buildbot.
>
> rgds
> jan i
>


And a addon to the general discussion, if I may bring it down to something
we can handle again.

We can wish anything (especially around christmas), but fact is:
- We have tried to change the ASF buildbots used, to generate releases (the
configure options are set differently) for as long as we have been a TLP.
- We have had a MAC buildbot for several month now, and its still not
production
- Last time (about 6month ago) when infra (in person me) rolled a centOS vm
for buildbot, the interest was less the time it cost to write a mail so in
fact it was abendoned.
- There are no (and as far as I can see have been no) jira for a 32bit
centOS.
- Currently we have no release manager, and as far as I know nobody have
asked to become a release manager.

So may I politely ask, what have changed, that we now believe this will all
go away, and we can have it all solved in a short time ?

To me the above points are months of work, until tested and stable, and
considering we havent even started, I think it is fair to ask, do we really
want to wait until this magically happens ?

Sorry for being very direct (its my danish style), but we need to get
things moving instead of just dreaming...so who will take care of which of
the above points ?

I will make sure (with my infra hat on), that when the centOS (64bit) is
needed, (meaning somebody will actually care for it, after having cared for
the MAC buildbot, which Infra spent money on), then it will be there.

rgds
jan i.

>
>
>>
>> --
>> Rory O'Farrell 
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>
>

Re: Budapest and thereafter.

[jan i]

On 8 December 2014 at 19:50, Rory O'Farrell  wrote:

> On Mon, 08 Dec 2014 19:37:41 +0100
> Marcus  wrote:
>
> > Am 12/08/2014 06:31 PM, schrieb Rory O'Farrell:
> > > On Mon, 8 Dec 2014 09:19:17 -0800
> > > Kay Schenk  wrote:
> > >
> > >> And, I didn't review the infra ticket on Cent OS carefully. Until we
> make a
> > >> decision that we do not want to provide Linux-32 binaries, we need a
> 32-bit
> > >> Cent OS 5 buildbot.  I'' create a new ticket today.
> > >
> > > Possibly because most OO developers have 64 bit computers, we tend to
> >  > overlook the need for 32 bit versions of OO. We should not lose sight
> >  > of the need for such versions - it as a way of introducing people
> >  > using older machines.  Most of the older people I know (mostly 65+,
> >  > retired) are using 32 bit machines, often handed down from their
> >  > children.
> >
> > right, but do you really mean - or have heard/read - that they get Linux
> > machines from their children? I think it will be still Windows - and
> > here 32 or 64 bit doesn't matter.
> >
> > But anyway, yes we still need 32-bit binaries for Linux.
> >
> > Marcus
> >
> When I am asked I guide them to 32 bit linux to help older computers work
> well. If we drop 32 bit for linux, we effectively abandon that area to
> LibO; we have enough of an uphill fight regaining users from the inbuilt
> installation of LibO on the distros as it is.  We shouldn't abandon that
> area.
>

I dont follow the notion of "abandon that area", we have never had a 32bit
centOS buildbot or for that matter a 64bit, so we are not abandoning
anything, we are instead expanding.

I dont know if we made releases available on centOS earlier, but for sure
we did not do it with ASF buildbot.

rgds
jan i


>
> --
> Rory O'Farrell 
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Budapest and thereafter.

[Marcus]

Am 12/08/2014 07:50 PM, schrieb Rory O'Farrell:

On Mon, 08 Dec 2014 19:37:41 +0100
Marcus  wrote:


Am 12/08/2014 06:31 PM, schrieb Rory O'Farrell:

On Mon, 8 Dec 2014 09:19:17 -0800
Kay Schenk   wrote:


And, I didn't review the infra ticket on Cent OS carefully. Until we make a
decision that we do not want to provide Linux-32 binaries, we need a 32-bit
Cent OS 5 buildbot.  I'' create a new ticket today.


Possibly because most OO developers have 64 bit computers, we tend to

  >  overlook the need for 32 bit versions of OO. We should not lose sight
  >  of the need for such versions - it as a way of introducing people
  >  using older machines.  Most of the older people I know (mostly 65+,
  >  retired) are using 32 bit machines, often handed down from their
  >  children.

right, but do you really mean - or have heard/read - that they get Linux
machines from their children? I think it will be still Windows - and
here 32 or 64 bit doesn't matter.

But anyway, yes we still need 32-bit binaries for Linux.

Marcus


When I am asked I guide them to 32 bit linux to help older computers work


OK

> well. If we drop 32 bit for linux, we effectively abandon that area to
> LibO; we have enough of an uphill fight regaining users from the
> inbuilt installation of LibO on the distros as it is.  We shouldn't
> abandon that area.

Of course not. Nobody has said this. ;-)

Marcus

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

Re: Budapest and thereafter.

[Rory O'Farrell]

On Mon, 08 Dec 2014 19:37:41 +0100
Marcus  wrote:

> Am 12/08/2014 06:31 PM, schrieb Rory O'Farrell:
> > On Mon, 8 Dec 2014 09:19:17 -0800
> > Kay Schenk  wrote:
> >
> >> And, I didn't review the infra ticket on Cent OS carefully. Until we make a
> >> decision that we do not want to provide Linux-32 binaries, we need a 32-bit
> >> Cent OS 5 buildbot.  I'' create a new ticket today.
> >
> > Possibly because most OO developers have 64 bit computers, we tend to
>  > overlook the need for 32 bit versions of OO. We should not lose sight
>  > of the need for such versions - it as a way of introducing people
>  > using older machines.  Most of the older people I know (mostly 65+,
>  > retired) are using 32 bit machines, often handed down from their
>  > children.
> 
> right, but do you really mean - or have heard/read - that they get Linux 
> machines from their children? I think it will be still Windows - and 
> here 32 or 64 bit doesn't matter.
> 
> But anyway, yes we still need 32-bit binaries for Linux.
> 
> Marcus
> 
When I am asked I guide them to 32 bit linux to help older computers work well. 
If we drop 32 bit for linux, we effectively abandon that area to LibO; we have 
enough of an uphill fight regaining users from the inbuilt installation of LibO 
on the distros as it is.  We shouldn't abandon that area. 

-- 
Rory O'Farrell 

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

Re: Budapest and thereafter.

[Marcus]

Am 12/08/2014 06:31 PM, schrieb Rory O'Farrell:

On Mon, 8 Dec 2014 09:19:17 -0800
Kay Schenk  wrote:


And, I didn't review the infra ticket on Cent OS carefully. Until we make a
decision that we do not want to provide Linux-32 binaries, we need a 32-bit
Cent OS 5 buildbot.  I'' create a new ticket today.


Possibly because most OO developers have 64 bit computers, we tend to

> overlook the need for 32 bit versions of OO. We should not lose sight
> of the need for such versions - it as a way of introducing people
> using older machines.  Most of the older people I know (mostly 65+,
> retired) are using 32 bit machines, often handed down from their
> children.

right, but do you really mean - or have heard/read - that they get Linux 
machines from their children? I think it will be still Windows - and 
here 32 or 64 bit doesn't matter.


But anyway, yes we still need 32-bit binaries for Linux.

Marcus


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

Re: Budapest and thereafter.

[Marcus]

Am 12/08/2014 02:32 PM, schrieb Andrea Pescetti:

On 07/12/2014 jan i wrote:

On Sunday, December 7, 2014, Kay Schenk wrote:

On Sun, Dec 7, 2014 at 9:30 AM, jan i wrote:

Maybe its just me, but it seems all of the above is forgotten, at
least I
cannot see any mentions on this ML.


Indeed, and thanks for raising it! The two main discussions we had in
Budapest concerned the Infrastructure actions (and here I already
reported with the message Kay indicated) and the next release (and on
this I didn't have time to report yet; good that you started this
discussion).


Regarding the next release. Of course, most of us have no idea what the
discussion in Budapest actually entailed with respect to this, but the
latest discussion can be found from this link --
http://markmail.org/message/aehavvvhiz6les6q


Yes, basically we agreed with that plan, but an important new addition
we have is digital signing (to be precise, digital signing that Windows
will accept).


My take on the above is that a goal before the next release was to
have a
complete buildbot infrastructure in place at Apache ...

...making that a requirement for
a release seems to be a perfect excuse to continue talking.
We could on the other hand, if we pulled together, bring out a windows
release in a couple of weeks, with digital signing


I'm open to both options: re-releasing the Windows 4.1.1 binaries with
digital signing or releasing 4.1.2 (source + binaries for all platforms)
with digital signing, possible new languages and bugfixes.

We could actually do both, if you believe it makes sense:
- signed 4.1.1 (next Windows binaries only) by end of December
- 4.1.2 in January


IMHO this doesn't make sense and would be just a waste of resources, 
when doing 2 releases in such a short time frame.


But I would tend to do only the bigger release (4.1.2) - let's say in 
January/February. When ...



Setting a translation deadline early in 2015 (like 4 January or 11
January) would allow us to work with translators during the end-of-year
holidays and get a couple more languages in, as well as identifying the
bugs to be fixed. For example
https://issues.apache.org/ooo/show_bug.cgi?id=125567 is a good
candidate, but still needs substantial investigation it seems.


.. we first have solved 2 things:

- A new release manager (like Kay already mentioned) is also needed. 
Please remember I've tried to list all tasks for a release here:


https://cwiki.apache.org/confluence/display/OOOUSERS/Release+Planning+Template

- Of course working buildbots are key as well when the release manager 
hasn't the ability/resources to do the builds on her/his own. ;-).


My 2 ct.

Marcus


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

Re: Budapest and thereafter.

[Rory O'Farrell]

On Mon, 8 Dec 2014 09:19:17 -0800
Kay Schenk  wrote:

> On Mon, Dec 8, 2014 at 5:32 AM, Andrea Pescetti  wrote:
> 
> > On 07/12/2014 jan i wrote:
> >
> >> On Sunday, December 7, 2014, Kay Schenk wrote:
> >>
> >>> On Sun, Dec 7, 2014 at 9:30 AM, jan i wrote:
> >>>
>  Maybe its just me, but it seems all of the above is forgotten, at least
>  I
>  cannot see any mentions on this ML.
> 
> >>>
> > Indeed, and thanks for raising it! The two main discussions we had in
> > Budapest concerned the Infrastructure actions (and here I already reported
> > with the message Kay indicated) and the next release (and on this I didn't
> > have time to report yet; good that you started this discussion).
> >
> >  Regarding the next release. Of course, most of us have no idea what the
> >>> discussion in Budapest actually entailed with respect to this, but the
> >>> latest discussion  can be found from this link --
> >>>   http://markmail.org/message/aehavvvhiz6les6q
> >>>
> >>
> > Yes, basically we agreed with that plan, but an important new addition we
> > have is digital signing (to be precise, digital signing that Windows will
> > accept).
> >
> >  My take on the above is that a goal before the next release was to have a
> >>> complete buildbot infrastructure in place at Apache ...
> >>>
> >> ...making that a requirement for
> >> a release seems to be a perfect excuse to continue talking.
> >> We could on the other hand, if we pulled together, bring out a windows
> >> release in a couple of weeks, with digital signing
> >>
> >
> > I'm open to both options: re-releasing the Windows 4.1.1 binaries with
> > digital signing or releasing 4.1.2 (source + binaries for all platforms)
> > with digital signing, possible new languages and bugfixes.
> >
> > We could actually do both, if you believe it makes sense:
> > - signed 4.1.1 (next Windows binaries only) by end of December
> >
> 
> I don't like the above idea at all! I think this would be VERY confusing to
> our user community.
> 
> 
> > - 4.1.2 in January
> >
> 
> I think a release of any kind in January is too optimistic.
> 
> My feeling is that until we get buildbots in place on Apache gear, with
> testing, it's kind of premature to discuss a next release. This, of course,
> means that all binaries for all languages will need to be built on Apache
> buildbot. Will space be an issue?
> 
> And, we need a  new release manager.
> 
> And, I didn't review the infra ticket on Cent OS carefully. Until we make a
> decision that we do not want to provide Linux-32 binaries, we need a 32-bit
> Cent OS 5 buildbot.  I'' create a new ticket today.

Possibly because most OO developers have 64 bit computers, we tend to overlook 
the need for 32 bit versions of OO. We should not lose sight of the need for 
such versions - it as a way of introducing people using older machines.  Most 
of the older people I know (mostly 65+, retired) are using 32 bit machines, 
often handed down from their children.

RoryOF

> 
> > Setting a translation deadline early in 2015 (like 4 January or 11
> > January) would allow us to work with translators during the end-of-year
> > holidays and get a couple more languages in, as well as identifying the
> > bugs to be fixed. For example https://issues.apache.org/ooo/
> > show_bug.cgi?id=125567 is a good candidate, but still needs substantial
> > investigation it seems.
> >
> >  This is of course only my opinion and possibly a very lonely one.
> >>
> >
> > It's a good one. Let's see how to move on.
> >
> > Regards,
> >   Andrea.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
> >
> 
> 
> -- 
> -
> MzK
> 
> "There's a bit of magic in everything,
>   and some loss to even things out."
> -- Lou Reed


-- 
Rory O'Farrell 

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

Re: Budapest and thereafter.

[Kay Schenk]

On Mon, Dec 8, 2014 at 5:32 AM, Andrea Pescetti  wrote:

> On 07/12/2014 jan i wrote:
>
>> On Sunday, December 7, 2014, Kay Schenk wrote:
>>
>>> On Sun, Dec 7, 2014 at 9:30 AM, jan i wrote:
>>>
 Maybe its just me, but it seems all of the above is forgotten, at least
 I
 cannot see any mentions on this ML.

>>>
> Indeed, and thanks for raising it! The two main discussions we had in
> Budapest concerned the Infrastructure actions (and here I already reported
> with the message Kay indicated) and the next release (and on this I didn't
> have time to report yet; good that you started this discussion).
>
>  Regarding the next release. Of course, most of us have no idea what the
>>> discussion in Budapest actually entailed with respect to this, but the
>>> latest discussion  can be found from this link --
>>>   http://markmail.org/message/aehavvvhiz6les6q
>>>
>>
> Yes, basically we agreed with that plan, but an important new addition we
> have is digital signing (to be precise, digital signing that Windows will
> accept).
>
>  My take on the above is that a goal before the next release was to have a
>>> complete buildbot infrastructure in place at Apache ...
>>>
>> ...making that a requirement for
>> a release seems to be a perfect excuse to continue talking.
>> We could on the other hand, if we pulled together, bring out a windows
>> release in a couple of weeks, with digital signing
>>
>
> I'm open to both options: re-releasing the Windows 4.1.1 binaries with
> digital signing or releasing 4.1.2 (source + binaries for all platforms)
> with digital signing, possible new languages and bugfixes.
>
> We could actually do both, if you believe it makes sense:
> - signed 4.1.1 (next Windows binaries only) by end of December
>

I don't like the above idea at all! I think this would be VERY confusing to
our user community.


> - 4.1.2 in January
>

I think a release of any kind in January is too optimistic.

My feeling is that until we get buildbots in place on Apache gear, with
testing, it's kind of premature to discuss a next release. This, of course,
means that all binaries for all languages will need to be built on Apache
buildbot. Will space be an issue?

And, we need a  new release manager.

And, I didn't review the infra ticket on Cent OS carefully. Until we make a
decision that we do not want to provide Linux-32 binaries, we need a 32-bit
Cent OS 5 buildbot.  I'' create a new ticket today.


> Setting a translation deadline early in 2015 (like 4 January or 11
> January) would allow us to work with translators during the end-of-year
> holidays and get a couple more languages in, as well as identifying the
> bugs to be fixed. For example https://issues.apache.org/ooo/
> show_bug.cgi?id=125567 is a good candidate, but still needs substantial
> investigation it seems.
>
>  This is of course only my opinion and possibly a very lonely one.
>>
>
> It's a good one. Let's see how to move on.
>
> Regards,
>   Andrea.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
-
MzK

"There's a bit of magic in everything,
  and some loss to even things out."
-- Lou Reed

Re: Budapest and thereafter.

[Andrea Pescetti]

On 07/12/2014 jan i wrote:

On Sunday, December 7, 2014, Kay Schenk wrote:

On Sun, Dec 7, 2014 at 9:30 AM, jan i wrote:

Maybe its just me, but it seems all of the above is forgotten, at least I
cannot see any mentions on this ML.


Indeed, and thanks for raising it! The two main discussions we had in 
Budapest concerned the Infrastructure actions (and here I already 
reported with the message Kay indicated) and the next release (and on 
this I didn't have time to report yet; good that you started this 
discussion).



Regarding the next release. Of course, most of us have no idea what the
discussion in Budapest actually entailed with respect to this, but the
latest discussion  can be found from this link --
  http://markmail.org/message/aehavvvhiz6les6q


Yes, basically we agreed with that plan, but an important new addition 
we have is digital signing (to be precise, digital signing that Windows 
will accept).



My take on the above is that a goal before the next release was to have a
complete buildbot infrastructure in place at Apache ...

...making that a requirement for
a release seems to be a perfect excuse to continue talking.
We could on the other hand, if we pulled together, bring out a windows
release in a couple of weeks, with digital signing


I'm open to both options: re-releasing the Windows 4.1.1 binaries with 
digital signing or releasing 4.1.2 (source + binaries for all platforms) 
with digital signing, possible new languages and bugfixes.


We could actually do both, if you believe it makes sense:
- signed 4.1.1 (next Windows binaries only) by end of December
- 4.1.2 in January

Setting a translation deadline early in 2015 (like 4 January or 11 
January) would allow us to work with translators during the end-of-year 
holidays and get a couple more languages in, as well as identifying the 
bugs to be fixed. For example 
https://issues.apache.org/ooo/show_bug.cgi?id=125567 is a good 
candidate, but still needs substantial investigation it seems.



This is of course only my opinion and possibly a very lonely one.


It's a good one. Let's see how to move on.

Regards,
  Andrea.

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

Re: Budapest and thereafter.

[jan i]

On Sunday, December 7, 2014, Kay Schenk  wrote:

> On Sun, Dec 7, 2014 at 9:30 AM, jan i >
> wrote:
>
> > Hi
> >
> > There was quite a number of AOO meetings in Budapest, with different
> > constellasions of people.
> >
> > Of course no decisions were made, that needs to happen in here, but
> > expectations were set. Just to mention one, bring out a release fast,
> with
> > a few bug fixes and digital signing. Some of us was also asked if we
> would
> > give a hand under given circumstances.
> >
> > From my work with infra earlier this year we know that digital signing is
> > not a matter of programming, but merely a matter of release work,
> >
> > Maybe its just me, but it seems all of the above is forgotten, at least I
> > cannot see any mentions on this ML.
> >
>
> Regarding the next release. Of course, most of us have no idea what the
> discussion in Budapest actually entailed with respect to this, but the
> latest discussion  can be found from this link --
>
>  http://markmail.org/message/aehavvvhiz6les6q
>
> My take on the above is that a goal before the next release was to have a
> complete buildbot infrastructure in place at Apache to spin binaries from
> that rather than the previous process.
>
> We also received an update on this list from Andrea on some of the
> discussions with infra at ApacheConEU. See --
>
> http://markmail.org/message/6ymi35tajswcfsps


I was part of the infra discussions, which is why I promised to
(again) maintain the servers.


>
> With respect to CentOS 5, we need both a 32-bit and 64-bit on CentOS 5. Can
> you tell us anything about that?


There are no request for a  32bit cent-os 5, only for a 64bit.

I am a bit sceptic, "need" is a big word, we also needed the mac buildbot,
we have it, but its still not operational (infra delivered it some month
ago).

The cent-os 5 64bit will most likely come in a couple of weeks. It will be
setup with a dummy AOO user, since nobody have currently asked for access.


> We do need volunteers to help with the CentOS 5 builbot setups at some
> point once the VMs are established.


I think the same can be said about the mac buildbot.

The cent-vm was actually spinning about 6months ago, but was taken down for
several reasons.


>
> In summary, we have some tasks to do before springing into action on the
> next release.


We have waited for the better part of 2 years to get the buildbot system in
a better shape (see dates on jira tickets) so making that a requirement for
a release seems to be a perfect excuse to continue talking.

We could on the other hand, if we pulled together, bring out a windows
release in a couple of weeks, with digital signing, which would help a lot
of users.and show that our project can still achieve something.

This is of course only my opinion and possibly a very lonely one.

rgds
jan i


>
> > I would have loved to see some of the things come to life, and wanted to
> > help. However life must go. on, and just waiting for the sake if waiting
> > does not seem like a sensible thing to do.
> >
> > My question is (the same as in budapest) do we want to get things moving
> > and who wants to make a difference ?
> >
> > AOO is a great project, please lets not kill it by silence and lack of
> > activiyif YOU care time is right to help.
> >
> > just my opinion.
> > rgds
> > jan i
> >
> >
> > --
> > Sent from My iPad, sorry for any misspellings.
> >
>
>
>
> --
>
> -
> MzK
>
> "There's a bit of magic in everything,
>   and some loss to even things out."
> -- Lou Reed
>


-- 
Sent from My iPad, sorry for any misspellings.

Re: Budapest and thereafter.

[Kay Schenk]

On Sun, Dec 7, 2014 at 9:30 AM, jan i  wrote:

> Hi
>
> There was quite a number of AOO meetings in Budapest, with different
> constellasions of people.
>
> Of course no decisions were made, that needs to happen in here, but
> expectations were set. Just to mention one, bring out a release fast, with
> a few bug fixes and digital signing. Some of us was also asked if we would
> give a hand under given circumstances.
>
> From my work with infra earlier this year we know that digital signing is
> not a matter of programming, but merely a matter of release work,
>
> Maybe its just me, but it seems all of the above is forgotten, at least I
> cannot see any mentions on this ML.
>

Regarding the next release. Of course, most of us have no idea what the
discussion in Budapest actually entailed with respect to this, but the
latest discussion  can be found from this link --

 http://markmail.org/message/aehavvvhiz6les6q

My take on the above is that a goal before the next release was to have a
complete buildbot infrastructure in place at Apache to spin binaries from
that rather than the previous process.

We also received an update on this list from Andrea on some of the
discussions with infra at ApacheConEU. See --

http://markmail.org/message/6ymi35tajswcfsps

With respect to CentOS 5, we need both a 32-bit and 64-bit on CentOS 5. Can
you tell us anything about that?

We do need volunteers to help with the CentOS 5 builbot setups at some
point once the VMs are established.

In summary, we have some tasks to do before springing into action on the
next release.


> I would have loved to see some of the things come to life, and wanted to
> help. However life must go. on, and just waiting for the sake if waiting
> does not seem like a sensible thing to do.
>
> My question is (the same as in budapest) do we want to get things moving
> and who wants to make a difference ?
>
> AOO is a great project, please lets not kill it by silence and lack of
> activiyif YOU care time is right to help.
>
> just my opinion.
> rgds
> jan i
>
>
> --
> Sent from My iPad, sorry for any misspellings.
>



-- 
-
MzK

"There's a bit of magic in everything,
  and some loss to even things out."
-- Lou Reed

Budapest and thereafter.

[jan i]

Hi

There was quite a number of AOO meetings in Budapest, with different
constellasions of people.

Of course no decisions were made, that needs to happen in here, but
expectations were set. Just to mention one, bring out a release fast, with
a few bug fixes and digital signing. Some of us was also asked if we would
give a hand under given circumstances.

>From my work with infra earlier this year we know that digital signing is
not a matter of programming, but merely a matter of release work,

Maybe its just me, but it seems all of the above is forgotten, at least I
cannot see any mentions on this ML.

I would have loved to see some of the things come to life, and wanted to
help. However life must go. on, and just waiting for the sake if waiting
does not seem like a sensible thing to do.

My question is (the same as in budapest) do we want to get things moving
and who wants to make a difference ?

AOO is a great project, please lets not kill it by silence and lack of
activiyif YOU care time is right to help.

just my opinion.
rgds
jan i


-- 
Sent from My iPad, sorry for any misspellings.