Re: Release Manager for 4.2.0?

[Matthias Seidel]

Am 18.06.2017 um 16:47 schrieb Andrea Pescetti:
> Matthias Seidel wrote:
>> Bouncing up your mail from march...
>
> Not only from March, but from March 2016!

Wow, didn't even notice it...
But I must have thought it was important because I kept it in my
archive! ;-)

>
>> Am 27.03.2016 um 22:13 schrieb Andrea Pescetti:
>>> 2) Localization. I got shell access to the Pootle server a few days
>>> ago. I'm still looking around, and if someone else want to join this
>>> is an important part. We need to have a solid process for updating
>>> translations (the full route: new strings in code -> Pootle -> back to
>>> code -> in localized builds) in place.
>>
>> This is the part I would be interested to help!
>> Pootle synchronisation is essential for 4.2.0 and beyond.
>
> Good! So the first step would be that you try exporting a language
> (likely German in you case) from Pootle to SDF and check how it looks.
>
> While I assumed Pootle was aligned with 4.1.x (no strings are added
> within the 4.1.x series) Ariel did some work in early 2017 and found
> out that actually Pootle reflects some other, not perfectly clear,
> status of code.
>
> Anyway, the first action I suggest is:
>
> 1) Download German PO files from https://translate.apache.org/de/ (you
> will need to login; I've just given you permission to download the PO
> files in case you didn't have them)

Yes, that did work!
I will try the next steps...

And I just learned what the KeyID (lang="kid") is for, may be helpful!

Regards, Matthias

>
> 2) Convert the PO files to SDF; search "sdf" in
> https://wiki.openoffice.org for documentation
>
> 3) Compare the files you obtain with those at
> http://svn.apache.org/viewvc/openoffice/branches/AOO413/extras/l10n/source/de/
>
> (note: it's a huge text file, use some reliable editor)
>
> 4) You can also build the AOO414 branch -or trunk- with the new SDF if
> you want to have some fun.
>
> This is a first check to understand how stuff works and the
> translation status. Feel free to open a new dedicated discussion for
> follow-up if you need some more information. Note that I only know the
> high-level steps but I'm not familiar with details, so some
> documentation digging will still be needed.
>
> Regards,
>   Andrea.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Release Manager for 4.2.0?

[Andrea Pescetti]

Matthias Seidel wrote:

Bouncing up your mail from march...


Not only from March, but from March 2016!


Am 27.03.2016 um 22:13 schrieb Andrea Pescetti:

2) Localization. I got shell access to the Pootle server a few days
ago. I'm still looking around, and if someone else want to join this
is an important part. We need to have a solid process for updating
translations (the full route: new strings in code -> Pootle -> back to
code -> in localized builds) in place.


This is the part I would be interested to help!
Pootle synchronisation is essential for 4.2.0 and beyond.


Good! So the first step would be that you try exporting a language 
(likely German in you case) from Pootle to SDF and check how it looks.


While I assumed Pootle was aligned with 4.1.x (no strings are added 
within the 4.1.x series) Ariel did some work in early 2017 and found out 
that actually Pootle reflects some other, not perfectly clear, status of 
code.


Anyway, the first action I suggest is:

1) Download German PO files from https://translate.apache.org/de/ (you 
will need to login; I've just given you permission to download the PO 
files in case you didn't have them)


2) Convert the PO files to SDF; search "sdf" in 
https://wiki.openoffice.org for documentation


3) Compare the files you obtain with those at
http://svn.apache.org/viewvc/openoffice/branches/AOO413/extras/l10n/source/de/
(note: it's a huge text file, use some reliable editor)

4) You can also build the AOO414 branch -or trunk- with the new SDF if 
you want to have some fun.


This is a first check to understand how stuff works and the translation 
status. Feel free to open a new dedicated discussion for follow-up if 
you need some more information. Note that I only know the high-level 
steps but I'm not familiar with details, so some documentation digging 
will still be needed.


Regards,
  Andrea.

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

Re: Release Manager for 4.2.0?

[Matthias Seidel]

Hi Andrea,

Bouncing up your mail from march...

Am 27.03.2016 um 22:13 schrieb Andrea Pescetti:
> On 29/01/2016 Andrea Pescetti wrote:
>> For 4.2.0 we need a Release Manager. I would prefer NOT to be the
>> Release Manager for 4.2.0 since I'm finding that in this period I can
>> help more productively with tasks that do not require constant
>> interaction ...
>> I am surely available to have a significant role in the 4.2.0 release
>
> A few days after writing this, almost 2 months ago, sudden events left
> me incapacitated to make any significant contributions until very
> recently. I'm still unable to make long-term commitments.
>
> Anyway, there are some issues we need to get done as a team before
> appointing a release manager makes sense:
>
> 1) Enough code. Done. The merge of the recent gbuild work totally
> justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny
> fraction of the fixes that (at that time) were available on trunk. So
> here we are already OK, and we've been OK for months.
>
> 2) Localization. I got shell access to the Pootle server a few days
> ago. I'm still looking around, and if someone else want to join this
> is an important part. We need to have a solid process for updating
> translations (the full route: new strings in code -> Pootle -> back to
> code -> in localized builds) in place.

This is the part I would be interested to help!
Pootle synchronisation is essential for 4.2.0 and beyond.

Regards, Matthias

>
> 3) Buildbots and ASF-owned build machines. Buildbots are not essential
> for a release: 4.1.2 was built (like all previous releases in history)
> on non-ASF hardware; even if we build 4.2.0 on ASF-owned hardware, we
> can't use buildbots for it; we need to setup new systems. Those who
> read the infrastructure@ list can see the discussion I started there
> yesterday. Still, having buildbots helps QA and having ASF-owned build
> machines is an important investment for the project: at that point we
> will be able to make a release within days, not months. We should make
> as much progress as we can here. Again, if anybody can help, this is
> an important area.
>
> 4) There are several optimizations I have in mind, especially on
> reducing a bit our binary size on Linux (trust me, it is really a pain
> to commit all those binaries to SVN, or to any version control
> system). But they are not essential.
>
> I have just committed to the devtools/ area the scripts we (mainly
> Juergen) used to build the 4.1.2 release, with specs of the build
> machines. I've had them since last October, but I never committed
> them. They are a first step if we want to build our release binaries
> on ASF hardware: they contain build options and config.log to have
> some more information on the environment.
>
> My next priorities will be localization (especially, re-exporting the
> Italian translation to Pootle and re-importing it) and and a
> proof-of-concept VM for building releases on Linux (64 bit) based on
> the above scripts. There is plenty of room for other to jump in (Linux
> 32, Windows, Mac; or localization management) so please do!
>
> Regards,
>   Andrea.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>




smime.p7s
Description: S/MIME Cryptographic Signature

RE: Release Manager for 4.2.0?

[Dennis E. Hamilton]

I don't have a good place to put this, and 4.2.0 may not be the way to consider 
it, if we are also counting on an early (this year) 4.2.0 to also provide 
important maintenance fixes and any security catch-ups too.

One major change that the TDF made to LibreOffice is very important.  Instead 
of producing complete binary sets (Windows x86, MacOSX, Linux32, and Linux64) 
for *each* localization, LibreOffice provides one complete set for *all* 
localizations.  The off-line Help is only in English, but localized off-line 
Helps can be obtained as small downloads.  The on-line helps reached by default 
are localized.

You can imagine how this simplifies deployment, including QA and binding votes. 
 They have also been using Windows .msi binaries, with Microsoft's signing 
method, for some time.

Somehow, it would be good to have a checklist of the kinds of things that we 
would like to try and confirm using rebuilds of a stable version, not just for 
emergency releases.  There are a number of deployment improvements that could 
be tested and QA'd that way without worrying about regressions inside of a 
feature release.

Just a thought.

 - Dennis

> -Original Message-
> From: Patricia Shanahan [mailto:p...@acm.org]
> Sent: Friday, August 19, 2016 11:30
> To: dev@openoffice.apache.org
> Subject: Re: Release Manager for 4.2.0?
> 
> 
> 
> On 8/19/2016 10:41 AM, Kay sch...@apache.org wrote:
> >
> > On 01/28/2016 04:06 PM, Andrea Pescetti wrote:
> >> As I wrote a few day ago, in theory it would be good to release
> >> OpenOffice 4.2.0 in February. If it happens a bit later it wouldn't
> be a
> >> big issue, but I believe that, in the constant balance between
> periods
> >> where we are focused on talks (internal to OpenOffice and with the
> >> enlarged community) and periods where we are more focused on the
> >> OpenOffice product, it's time to start working again towards a
> release.
> >>
> >> For 4.2.0 we need a Release Manager. I would prefer NOT to be the
> >> Release Manager for 4.2.0 since I'm finding that in this period I can
> >> help more productively with tasks that do not require constant
> >> interaction than with tasks that require a constant monitoring of
> >> project channels.
> >>
> >> I am surely available to have a significant role in the 4.2.0
> release,
> >> especially with getting localization working again (actually, this
> mail
> >> also serves as announcement that I am going to ask for higher
> privileges
> >> on the Pootle server in order to check the translation workflow); but
> if
> >> someone else steps in as a Release Manager we could deliver earlier.
> >>
> >> So if anyone is interested feel free to discuss this on list, or to
> >> contact me off-list if you prefer, or to discuss in person at FOSDEM
> >> next weekend!
> >>
> >> Regards,
> >>   Andrea.
> >>
> >
> > Hi all--
> >
> > I am volunteering to be release manager for 4.2.0.  I have been
> involved
> > in all the AOO releases since 3.40, and I'm familiar with the process.
> > Like all of us involved with the project, I am a volunteer. Due to
> this,
> > I can not provide an expected release date. Releases, as we know are
> > community efforts. We'll release when we feel 4.2.0 is ready.
> >
> > So, I will let this offer stand the weekend just in case someone else
> > feels they'd LOVE to do this. If we don't have any objections to my
> > being the next release manager over the next 72 hours, we can get
> > started next week ironing out what needs to be done. We will need LOTS
> > of help!
> 
> This looks ideal to me. I would like to learn the release processes, and
> try to document them as completely as possible. I would prefer to learn
> by watching and helping someone who already knows how it is done, than
> by jumping in the deep end and splashing about.
> 
> I have an agenda of constructing an emergency release procedure but it
> will be easier if I can first see how the normal process goes.
> 
> -
> 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: Release Manager for 4.2.0?

[Kay sch...@apache.org]

On 08/19/2016 08:20 PM, Keith N. McKenna wrote:
> 
>>>
>>
>> Hi all--
>>
>> I am volunteering to be release manager for 4.2.0.  I have been involved
>> in all the AOO releases since 3.40, and I'm familiar with the process.
>> Like all of us involved with the project, I am a volunteer. Due to this,
>> I can not provide an expected release date. Releases, as we know are
>> community efforts. We'll release when we feel 4.2.0 is ready.
>>
>> So, I will let this offer stand the weekend just in case someone else
>> feels they'd LOVE to do this. If we don't have any objections to my
>> being the next release manager over the next 72 hours, we can get
>> started next week ironing out what needs to be done. We will need LOTS
>> of help!
>>
>>
> Kay that is great for volunteering. I also will help wherever I can.
> 
> Keith
> 
> 

Thanks to all who responded for your support. I'm looking forward to
this new adventure!

-- 
Kay Schenk
Apache OpenOffice


"Things work out best for those who make
 the best of the way things work out."
 -- John Wooden

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

Re: Release Manager for 4.2.0?

[Kay Schenk]

...and back to this one...

On 03/27/2016 01:13 PM, Andrea Pescetti wrote:
> On 29/01/2016 Andrea Pescetti wrote:
>> For 4.2.0 we need a Release Manager. I would prefer NOT to be the
>> Release Manager for 4.2.0 since I'm finding that in this period I can
>> help more productively with tasks that do not require constant
>> interaction ...
>> I am surely available to have a significant role in the 4.2.0 release
> 
> A few days after writing this, almost 2 months ago, sudden events left
> me incapacitated to make any significant contributions until very
> recently. I'm still unable to make long-term commitments.
> 
> Anyway, there are some issues we need to get done as a team before
> appointing a release manager makes sense:
> 
> 1) Enough code. Done. The merge of the recent gbuild work totally
> justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny
> fraction of the fixes that (at that time) were available on trunk. So
> here we are already OK, and we've been OK for months.
> 
> 2) Localization. I got shell access to the Pootle server a few days ago.
> I'm still looking around, and if someone else want to join this is an
> important part. We need to have a solid process for updating
> translations (the full route: new strings in code -> Pootle -> back to
> code -> in localized builds) in place.

Can you give us a status update on Pootle export and import back to trunk?
The new translations are one of THE most important aspects of 4.2 in my
opinion. We might be adding about 4  new languages.

> 
> 3) Buildbots and ASF-owned build machines. Buildbots are not essential
> for a release: 4.1.2 was built (like all previous releases in history)
> on non-ASF hardware; even if we build 4.2.0 on ASF-owned hardware, we
> can't use buildbots for it; we need to setup new systems. Those who read
> the infrastructure@ list can see the discussion I started there
> yesterday. Still, having buildbots helps QA and having ASF-owned build
> machines is an important investment for the project: at that point we
> will be able to make a release within days, not months. We should make
> as much progress as we can here. Again, if anybody can help, this is an
> important area.
> 
> 4) There are several optimizations I have in mind, especially on
> reducing a bit our binary size on Linux (trust me, it is really a pain
> to commit all those binaries to SVN, or to any version control system).
> But they are not essential.
> 
> I have just committed to the devtools/ area the scripts we (mainly
> Juergen) used to build the 4.1.2 release, with specs of the build
> machines. I've had them since last October, but I never committed them.
> They are a first step if we want to build our release binaries on ASF
> hardware: they contain build options and config.log to have some more
> information on the environment.
> 
> My next priorities will be localization (especially, re-exporting the
> Italian translation to Pootle and re-importing it) and and a
> proof-of-concept VM for building releases on Linux (64 bit) based on the
> above scripts. There is plenty of room for other to jump in (Linux 32,
> Windows, Mac; or localization management) so please do!
> 
> Regards,
>   Andrea.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 

-- 

MzK

"Time spent with cats is never wasted."
   -- Sigmund Freud

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

Re: Release Manager for 4.2.0?

[Keith N. McKenna]

>>
> 
> Hi all--
> 
> I am volunteering to be release manager for 4.2.0.  I have been involved
> in all the AOO releases since 3.40, and I'm familiar with the process.
> Like all of us involved with the project, I am a volunteer. Due to this,
> I can not provide an expected release date. Releases, as we know are
> community efforts. We'll release when we feel 4.2.0 is ready.
> 
> So, I will let this offer stand the weekend just in case someone else
> feels they'd LOVE to do this. If we don't have any objections to my
> being the next release manager over the next 72 hours, we can get
> started next week ironing out what needs to be done. We will need LOTS
> of help!
> 
> 
Kay that is great for volunteering. I also will help wherever I can.

Keith




signature.asc
Description: OpenPGP digital signature

Re: Release Manager for 4.2.0?

[Marcus]

Am 08/19/2016 07:41 PM, schrieb Kay sch...@apache.org:


On 01/28/2016 04:06 PM, Andrea Pescetti wrote:

As I wrote a few day ago, in theory it would be good to release
OpenOffice 4.2.0 in February. If it happens a bit later it wouldn't be a
big issue, but I believe that, in the constant balance between periods
where we are focused on talks (internal to OpenOffice and with the
enlarged community) and periods where we are more focused on the
OpenOffice product, it's time to start working again towards a release.

For 4.2.0 we need a Release Manager. I would prefer NOT to be the
Release Manager for 4.2.0 since I'm finding that in this period I can
help more productively with tasks that do not require constant
interaction than with tasks that require a constant monitoring of
project channels.

I am surely available to have a significant role in the 4.2.0 release,
especially with getting localization working again (actually, this mail
also serves as announcement that I am going to ask for higher privileges
on the Pootle server in order to check the translation workflow); but if
someone else steps in as a Release Manager we could deliver earlier.

So if anyone is interested feel free to discuss this on list, or to
contact me off-list if you prefer, or to discuss in person at FOSDEM
next weekend!

Regards,
   Andrea.



Hi all--

I am volunteering to be release manager for 4.2.0.  I have been involved
in all the AOO releases since 3.40, and I'm familiar with the process.
Like all of us involved with the project, I am a volunteer. Due to this,
I can not provide an expected release date. Releases, as we know are
community efforts. We'll release when we feel 4.2.0 is ready.

So, I will let this offer stand the weekend just in case someone else
feels they'd LOVE to do this. If we don't have any objections to my
being the next release manager over the next 72 hours, we can get
started next week ironing out what needs to be done. We will need LOTS
of help!


thanks for volunteering. I'll support you where I can and when my spare 
time allows it.


Marcus


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

Re: Release Manager for 4.2.0?

[Patricia Shanahan]

On 8/19/2016 10:41 AM, Kay sch...@apache.org wrote:


On 01/28/2016 04:06 PM, Andrea Pescetti wrote:

As I wrote a few day ago, in theory it would be good to release
OpenOffice 4.2.0 in February. If it happens a bit later it wouldn't be a
big issue, but I believe that, in the constant balance between periods
where we are focused on talks (internal to OpenOffice and with the
enlarged community) and periods where we are more focused on the
OpenOffice product, it's time to start working again towards a release.

For 4.2.0 we need a Release Manager. I would prefer NOT to be the
Release Manager for 4.2.0 since I'm finding that in this period I can
help more productively with tasks that do not require constant
interaction than with tasks that require a constant monitoring of
project channels.

I am surely available to have a significant role in the 4.2.0 release,
especially with getting localization working again (actually, this mail
also serves as announcement that I am going to ask for higher privileges
on the Pootle server in order to check the translation workflow); but if
someone else steps in as a Release Manager we could deliver earlier.

So if anyone is interested feel free to discuss this on list, or to
contact me off-list if you prefer, or to discuss in person at FOSDEM
next weekend!

Regards,
  Andrea.



Hi all--

I am volunteering to be release manager for 4.2.0.  I have been involved
in all the AOO releases since 3.40, and I'm familiar with the process.
Like all of us involved with the project, I am a volunteer. Due to this,
I can not provide an expected release date. Releases, as we know are
community efforts. We'll release when we feel 4.2.0 is ready.

So, I will let this offer stand the weekend just in case someone else
feels they'd LOVE to do this. If we don't have any objections to my
being the next release manager over the next 72 hours, we can get
started next week ironing out what needs to be done. We will need LOTS
of help!


This looks ideal to me. I would like to learn the release processes, and
try to document them as completely as possible. I would prefer to learn
by watching and helping someone who already knows how it is done, than
by jumping in the deep end and splashing about.

I have an agenda of constructing an emergency release procedure but it
will be easier if I can first see how the normal process goes.

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

Re: Release Manager for 4.2.0?

[Kay Schenk]

On Sat, Jul 9, 2016 at 9:52 AM, Dennis E. Hamilton <dennis.hamil...@acm.org>
wrote:

> > -Original Message-
> > From: Andrea Pescetti [mailto:pesce...@apache.org]
> > Sent: Saturday, July 9, 2016 05:20
> > To: dev@openoffice.apache.org
> > Subject: Re: Release Manager for 4.2.0?
> [ ... ]
> > We have a "baseline", minimal system requirements that are supposed to
> > be valid for all the 4.x releases. We build releases on old (but still
> > supported) system to guarantee maximum compatibility for users. No ASF
> > buildbots match our baseline (they are all more advanced).
>

​Yes, we do have minimal baseline user system requirements, if you are
referring to:
​
 http://www.openoffice.org/dev_docs/source/sys_reqs_aoo41.html

​I understand this.​ What I'm not in agreement with is extending both  our
current "official" distribution build platform environments and these base
user requirements beyond the 4.1.x release.

But, it is true that non of the ASF buildbots satisfy our distribution
requirements in any case, and what do we want to do about this?

[more below]


[ ... ]
> > [Building this way involves] a fairly ordinary system
> > that is "specialized" since it is only available to one person. The best
> > thing would be to get the same system moved to ASF-owned VMs, accessible
> > to all PMC members who want to do so.
> [ ... ]
> At present, the discussion with
> > Infra is stalled as explained above.
> >
> [orcmid]
>
> It seems to me that we are seriously over-constrained here.
>
> The requirement that anyone should be able to build something akin to what
> we build to know a release candidate is acceptable (or for their own
> purposes) seems difficult to meet since the way current distributed
> binaries are prepared is with unknown settings and build configuration
> (including library, compiler and tool [version] dependencies).  Somehow
> that information must be captured and provided as part of the released
> source, giving others an opportunity to identify and address
> reproducibility problems.
>

​@Dennis, the build settings and environments are documented in:
​
 http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.2/

​The file at the top level:
​
http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.2/environments.txt?view=log

gives a bit more detail on the system environments but you'd have to search
out details for say CentOS5 to see what actual versions of libraries, etc
pertain.



> Having buildbots not at those same levels means that we can't assume
> buildbots provide binaries that work for the current oldest-supported
> platform for an AOO major version.


​That is absolutely correct and something I experienced on CentOS 6.7 a few
months ago. I could install but not run the Linux-32 bit AOO from the
buildbot due to glibc version differences.
​


>   Is it not the case that buildbots mainly provide a smoke test on the
> build process?  Verifying anything further depends on what developers do
> with the result.  (PS: I can't imagine reverting to Windows XP for a
> buildbot.)
>
> It might not be necessary to build on the same platform version that an
> executable is intended to run on.  The idea might be to build for the
> lowest-level of supported OS/runtime version.  Would not appropriate
> confirmation be by installation and operation on the lowest supported OS
> version and also the latest, hoping there is no smoke or breakage at either
> end?
>
> If there are breaking changes between the two ends of our confirmed
> operability, the question is then whether or not we provide adaptation at
> installation or at runtime.


​Currently we provide changes at installation due to our build process
nature.​

Runtime is preferable to prevent failures when there are OS updates or
> upgrades that don't require re-installation of application software
> products.
>

​I'm pretty certain this is not possible under our current architecture. We
use certain libraries for building, and we're basically a static monolithic
build at the end. I don't think our build process or architecture lends
itself to this kind of dynamism. A more knowledgeable developer than I
could certainly weigh in here. I think we would have to essentially retool
core components into something like extensions to enact what is suggested.


>
> Without such provisions, we will also fail to take advantage of advances
> in the platform that users see with other software products.  I am thinking
> of differences such as the font formatting and scaling issues introduced in
> Windows 7 and later, the changes of Java location on OS X, and encryption
> libraries on *nix flavors.  The OS certification and code signing
> requirements for latest Windo

RE: Release Manager for 4.2.0?

[Dennis E. Hamilton]

> -Original Message-
> From: Andrea Pescetti [mailto:pesce...@apache.org]
> Sent: Saturday, July 9, 2016 05:20
> To: dev@openoffice.apache.org
> Subject: Re: Release Manager for 4.2.0?
[ ... ]
> We have a "baseline", minimal system requirements that are supposed to
> be valid for all the 4.x releases. We build releases on old (but still
> supported) system to guarantee maximum compatibility for users. No ASF
> buildbots match our baseline (they are all more advanced).
[ ... ]
> [Building this way involves] a fairly ordinary system
> that is "specialized" since it is only available to one person. The best
> thing would be to get the same system moved to ASF-owned VMs, accessible
> to all PMC members who want to do so. 
[ ... ]
At present, the discussion with
> Infra is stalled as explained above.
> 
[orcmid] 

It seems to me that we are seriously over-constrained here.  

The requirement that anyone should be able to build something akin to what we 
build to know a release candidate is acceptable (or for their own purposes) 
seems difficult to meet since the way current distributed binaries are prepared 
is with unknown settings and build configuration (including library, compiler 
and tool [version] dependencies).  Somehow that information must be captured 
and provided as part of the released source, giving others an opportunity to 
identify and address reproducibility problems.  

Having buildbots not at those same levels means that we can't assume buildbots 
provide binaries that work for the current oldest-supported platform for an AOO 
major version.  Is it not the case that buildbots mainly provide a smoke test 
on the build process?  Verifying anything further depends on what developers do 
with the result.  (PS: I can't imagine reverting to Windows XP for a buildbot.)

It might not be necessary to build on the same platform version that an 
executable is intended to run on.  The idea might be to build for the 
lowest-level of supported OS/runtime version.  Would not appropriate 
confirmation be by installation and operation on the lowest supported OS 
version and also the latest, hoping there is no smoke or breakage at either end?

If there are breaking changes between the two ends of our confirmed 
operability, the question is then whether or not we provide adaptation at 
installation or at runtime.  Runtime is preferable to prevent failures when 
there are OS updates or upgrades that don't require re-installation of 
application software products.  

Without such provisions, we will also fail to take advantage of advances in the 
platform that users see with other software products.  I am thinking of 
differences such as the font formatting and scaling issues introduced in 
Windows 7 and later, the changes of Java location on OS X, and encryption 
libraries on *nix flavors.  The OS certification and code signing requirements 
for latest Windows and Macintosh versions also apply here.  There's more.

I'm not saying that we should change our approach to what is supported.  
Somehow, we must remove the brittleness from how we accomplish that and how 
others can confirm/reproduce it.

 - Dennis






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

Re: Release Manager for 4.2.0?

[Andrea Pescetti]

On 16/06/2016 Kay Schenk wrote:

On 03/27/2016 01:13 PM, Andrea Pescetti wrote:

Anyway, there are some issues we need to get done as a team ...before
appointing a release manager makes sense:

1) Enough code. Done. The merge of the recent gbuild work totally
justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny
fraction of the fixes that (at that time) were available on trunk. So
here we are already OK, and we've been OK for months.

2) Localization. I got shell access to the Pootle server a few days ago.
I'm still looking around, and if someone else want to join this is an
important part. We need to have a solid process for updating
translations (the full route: new strings in code -> Pootle -> back to
code -> in localized builds) in place.


As the localization changes are quite significant from 4.1.2 to 4.2.0,
can you give us an update on the porting process?  Are there
instructions, etc?


I haven't been able to check all of this yet, sorry. But Infra provided 
full access in the meantime, meaning that the bottleneck here is only on 
our side and not on the Infra side.



3) Buildbots and ASF-owned build machines. Buildbots are not essential
for a release: 4.1.2 was built (like all previous releases in history)
on non-ASF hardware; even if we build 4.2.0 on ASF-owned hardware, we
can't use buildbots for it; we need to setup new systems. ...

On this. Why can't we use the buildbot assuming we can get all of them
working satisfactorily? I know there are, for example, some library
upgrades/differences between the buildbots and what we've used in the
past, but if we're upgrading to a new version, why can't we just spec
this in the system requirements for 4.2.0?


We have a "baseline", minimal system requirements that are supposed to 
be valid for all the 4.x releases. We build releases on old (but still 
supported) system to guarantee maximum compatibility for users. No ASF 
buildbots match our baseline (they are all more advanced). 
Unfortunately, the discussion on this got stalled on the Infra list when 
Infra wrote it would be very problematic for them to create VMs for us 
matching our specifications - they decided to focus on only one, recent, 
Linux-based distribution for their Linux VMs. There might be solutions 
involving Docker, but this only makes things more complex.



Can we flesh out specs in this direction? New versions of software often
dictate system software changes.


The major difference would be, I think, in the required glibc version 
for Linux builds.



I really feel we should
move on from specialized release build hardware.


It is not specialized hardware in itself, it is a fairly ordinary system 
that is "specialized" since it is only available to one person. The best 
thing would be to get the same system moved to ASF-owned VMs, accessible 
to all PMC members who want to do so. At present, the discussion with 
Infra is stalled as explained above.


Regards,
  Andrea.

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

Re: Release Manager for 4.2.0?

[Kay Schenk]

On 06/16/2016 11:28 AM, Dennis E. Hamilton wrote:




-Original Message-
From: Kay Schenk [mailto:kay.sch...@gmail.com]
Sent: Thursday, June 16, 2016 09:55
To: dev@openoffice.apache.org
Subject: Re: Release Manager for 4.2.0?

[getting back to this .. see below]

On 03/27/2016 01:13 PM, Andrea Pescetti wrote:

On 29/01/2016 Andrea Pescetti wrote:

For 4.2.0 we need a Release Manager. I would prefer NOT to be the
Release Manager for 4.2.0 since I'm finding that in this period I can
help more productively with tasks that do not require constant
interaction ...
I am surely available to have a significant role in the 4.2.0 release


A few days after writing this, almost 2 months ago, sudden events left
me incapacitated to make any significant contributions until very
recently. I'm still unable to make long-term commitments.

Anyway, there are some issues we need to get done as a team before
appointing a release manager makes sense:

1) Enough code. Done. The merge of the recent gbuild work totally
justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny
fraction of the fixes that (at that time) were available on trunk. So
here we are already OK, and we've been OK for months.

[orcmid]

I am unclear about the state of the gbuild merge.  Was it done even though 
there are unresolved problems using it for building Windows binaries?


no, it was not...hopefully soon or  I need to test this out myself 
on my Linux-32 box.




[ ... ]




--

MzK

"Time spent with cats is never wasted."
   -- Sigmund Freud

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

RE: Release Manager for 4.2.0?

[Dennis E. Hamilton]

> -Original Message-
> From: Kay Schenk [mailto:kay.sch...@gmail.com]
> Sent: Thursday, June 16, 2016 09:55
> To: dev@openoffice.apache.org
> Subject: Re: Release Manager for 4.2.0?
> 
> [getting back to this .. see below]
> 
> On 03/27/2016 01:13 PM, Andrea Pescetti wrote:
> > On 29/01/2016 Andrea Pescetti wrote:
> >> For 4.2.0 we need a Release Manager. I would prefer NOT to be the
> >> Release Manager for 4.2.0 since I'm finding that in this period I can
> >> help more productively with tasks that do not require constant
> >> interaction ...
> >> I am surely available to have a significant role in the 4.2.0 release
> >
> > A few days after writing this, almost 2 months ago, sudden events left
> > me incapacitated to make any significant contributions until very
> > recently. I'm still unable to make long-term commitments.
> >
> > Anyway, there are some issues we need to get done as a team before
> > appointing a release manager makes sense:
> >
> > 1) Enough code. Done. The merge of the recent gbuild work totally
> > justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny
> > fraction of the fixes that (at that time) were available on trunk. So
> > here we are already OK, and we've been OK for months.
[orcmid] 

I am unclear about the state of the gbuild merge.  Was it done even though 
there are unresolved problems using it for building Windows binaries?

[ ... ]


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

Re: Release Manager for 4.2.0?

[Kay Schenk]

[getting back to this .. see below]

On 03/27/2016 01:13 PM, Andrea Pescetti wrote:

On 29/01/2016 Andrea Pescetti wrote:

For 4.2.0 we need a Release Manager. I would prefer NOT to be the
Release Manager for 4.2.0 since I'm finding that in this period I can
help more productively with tasks that do not require constant
interaction ...
I am surely available to have a significant role in the 4.2.0 release


A few days after writing this, almost 2 months ago, sudden events left
me incapacitated to make any significant contributions until very
recently. I'm still unable to make long-term commitments.

Anyway, there are some issues we need to get done as a team before
appointing a release manager makes sense:

1) Enough code. Done. The merge of the recent gbuild work totally
justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny
fraction of the fixes that (at that time) were available on trunk. So
here we are already OK, and we've been OK for months.

2) Localization. I got shell access to the Pootle server a few days ago.
I'm still looking around, and if someone else want to join this is an
important part. We need to have a solid process for updating
translations (the full route: new strings in code -> Pootle -> back to
code -> in localized builds) in place.


As the localization changes are quite significant from 4.1.2 to 4.2.0, 
can you give us an update on the porting process?  Are there 
instructions, etc?




3) Buildbots and ASF-owned build machines. Buildbots are not essential
for a release: 4.1.2 was built (like all previous releases in history)
on non-ASF hardware; even if we build 4.2.0 on ASF-owned hardware, we
can't use buildbots for it; we need to setup new systems. Those who read
the infrastructure@ list can see the discussion I started there
yesterday. Still, having buildbots helps QA and having ASF-owned build
machines is an important investment for the project: at that point we
will be able to make a release within days, not months. We should make
as much progress as we can here. Again, if anybody can help, this is an
important area.


On this. Why can't we use the buildbot assuming we can get all of them 
working satisfactorily? I know there are, for example, some library 
upgrades/differences between the buildbots and what we've used in the 
past, but if we're upgrading to a new version, why can't we just spec 
this in the system requirements for 4.2.0?
Can we flesh out specs in this direction? New versions of software often 
dictate system software changes.




4) There are several optimizations I have in mind, especially on
reducing a bit our binary size on Linux (trust me, it is really a pain
to commit all those binaries to SVN, or to any version control system).
But they are not essential.

I have just committed to the devtools/ area the scripts we (mainly
Juergen) used to build the 4.1.2 release, with specs of the build
machines. I've had them since last October, but I never committed them.
They are a first step if we want to build our release binaries on ASF
hardware: they contain build options and config.log to have some more
information on the environment.


OK, we will take an indepth look at this, but I really feel we should 
move on from specialized release build hardware.




My next priorities will be localization (especially, re-exporting the
Italian translation to Pootle and re-importing it) and and a
proof-of-concept VM for building releases on Linux (64 bit) based on the
above scripts. There is plenty of room for other to jump in (Linux 32,
Windows, Mac; or localization management) so please do!

Regards,
   Andrea.


Thanks for all this!



--

MzK

"Time spent with cats is never wasted."
   -- Sigmund Freud

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

Re: Release Manager for 4.2.0?

[FR web forum]

Hello all,
Any news for this next 4.2.0?

- Mail original -
De: "Andrea Pescetti" <pesce...@apache.org>
À: dev@openoffice.apache.org
Envoyé: Dimanche 27 Mars 2016 22:13:11
Objet: Re: Release Manager for 4.2.0?

On 29/01/2016 Andrea Pescetti wrote:
> For 4.2.0 we need a Release Manager. I would prefer NOT to be the
> Release Manager for 4.2.0 since I'm finding that in this period I can
> help more productively with tasks that do not require constant
> interaction ...
> I am surely available to have a significant role in the 4.2.0 release

A few days after writing this, almost 2 months ago, sudden events left 
me incapacitated to make any significant contributions until very 
recently. I'm still unable to make long-term commitments.

Anyway, there are some issues we need to get done as a team before 
appointing a release manager makes sense:

1) Enough code. Done. The merge of the recent gbuild work totally 
justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny 
fraction of the fixes that (at that time) were available on trunk. So 
here we are already OK, and we've been OK for months.

2) Localization. I got shell access to the Pootle server a few days ago. 
I'm still looking around, and if someone else want to join this is an 
important part. We need to have a solid process for updating 
translations (the full route: new strings in code -> Pootle -> back to 
code -> in localized builds) in place.

3) Buildbots and ASF-owned build machines. Buildbots are not essential 
for a release: 4.1.2 was built (like all previous releases in history) 
on non-ASF hardware; even if we build 4.2.0 on ASF-owned hardware, we 
can't use buildbots for it; we need to setup new systems. Those who read 
the infrastructure@ list can see the discussion I started there 
yesterday. Still, having buildbots helps QA and having ASF-owned build 
machines is an important investment for the project: at that point we 
will be able to make a release within days, not months. We should make 
as much progress as we can here. Again, if anybody can help, this is an 
important area.

4) There are several optimizations I have in mind, especially on 
reducing a bit our binary size on Linux (trust me, it is really a pain 
to commit all those binaries to SVN, or to any version control system). 
But they are not essential.

I have just committed to the devtools/ area the scripts we (mainly 
Juergen) used to build the 4.1.2 release, with specs of the build 
machines. I've had them since last October, but I never committed them. 
They are a first step if we want to build our release binaries on ASF 
hardware: they contain build options and config.log to have some more 
information on the environment.

My next priorities will be localization (especially, re-exporting the 
Italian translation to Pootle and re-importing it) and and a 
proof-of-concept VM for building releases on Linux (64 bit) based on the 
above scripts. There is plenty of room for other to jump in (Linux 32, 
Windows, Mac; or localization management) so please do!

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: Release Manager for 4.2.0?

[Dennis E. Hamilton]

> -Original Message-
> From: Damjan Jovanovic [mailto:dam...@apache.org]
> Sent: Tuesday, March 29, 2016 02:30
> To: Apache OO <dev@openoffice.apache.org>
> Subject: Re: Release Manager for 4.2.0?
[ ... ]
> 
> Let's rather research where AOO uses openssl instead of guessing.
> 
> I find the use of openssl for document encryption and signing highly
> unlikely, as NSS was used there to make use of Firefox's root CA
> certificates, and allow configuring personal digital signatures using
> the Firefox GUI.
[orcmid] 

I am confident that is not the case for Windows, where the OS certificate store 
is used for private keys and for managing them, such as choosing their email 
usage.  Whether an NSS library is in the path in any manner is unclear.  I 
operate on configurations that do not have Firefox installed.
> 
> So which modules use openssl?
> 
> $ grep openssl */prj/build.lst
> oox/prj/build.lst:ooxoox : vos cppu cppuhelper comphelper sal
> offapi sax basegfx xmlscript tools vcl BOOST:boost OPENSSL:openssl
> LIBXSLT:libxslt NULL
> openssl/prj/build.lst:ssl  openssl  :  soltools external EXPAT:expat
> NULL
> openssl/prj/build.lst:ssl  openssl usr1   -   all
>ssl_mkout NULL
> openssl/prj/build.lst:ssl  openssl nmake  -   all
>ssl_openssl NULL
> python/prj/build.lst:pypython:SO:so_prereq solenv
> OPENSSL:openssl NULL
> redland/prj/build.lst:rld redland : stlport soltools
> LIBXML2:libxml2 LIBXSLT:libxslt OPENSSL:openssl NULL
> ucb/prj/build.lst:uc ucb : cppuhelper CURL:curl OPENSSL:openssl
> LIBXML2:libxml2 LIBXSLT:libxslt offapi sal salhelper ucbhelper udkapi
> comphelper SERF:serf tools NULL
> 
> Eliminating the openssl module itself from the above results, we have
> dependencies to it in oox, python, redland, and ucb.
> 
> Oox (used for OOXML, not ODF) uses it in the short
> lclCheckEncryptionData() function to detect encryption. It uses it
> exclusively for AES crypto.
> 
> Python could use it for just about anything, but we don't care because
> Python is itself optional.
> 
> Redland is an RDF library. It is used by unoxml. Not sure for what.
[orcmid] 

There are some manifest.rdf files included as boilerplate in ODF 1.2 packages.  
They are produced automatically.  I don't think they are consumed in any 
manner, but they might be parsed anyhow [;<).  They are included in signed 
packages and they are encrypted in encrypted packages.  They have no dependency 
in the ODF specification.  So far, they are there for mining of document 
metadata by external products.

PS: Handling of external entities in XML files can lead to use of internet 
transport.  Not certain what the use case might be.  It is not something that 
would be done with AOO-created XML inside ODF.

PPS: The access to external components from within ODF documents can involve 
Internet transport.  Won't this exercise the dependency from CURL that Don 
Lewis mentions?

> 
> Ucb apparently uses it for webdav. It doesn't call openssl APIs, but
> links to openssl because it uses serf.
[orcmid] 

WebDAV servers can require negotiation of HTTP authentication.  That may be the 
reason for this.  WebDAV protocol is atop HTTP.

> 
> Serf needs openssl and is only used by ucb.
> 
> Damjan
> 
> -
> 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: Release Manager for 4.2.0?

[Damjan Jovanovic]

On Mon, Mar 28, 2016 at 10:59 PM, Don Lewis  wrote:
> On 28 Mar, Pedro Giffuni wrote:
>> Hi Don;
>>
>>> On 28 Mar, Pedro Giffuni wrote:
>>> > In reply to Don,
>>>
>>> >> The versions of openssl and curl badly need updating for the same
>>> >> reason, and there is one CVE for serf.
>>> >
>>> > FreeBSD casually keeps some backported updates for the same openssl
>>> > version AOO uses:
>>> >
>>> > https://svnweb.freebsd.org/base/stable/9/crypto/openssl/?view=log
>>> >
>>> > It should be pretty straightforward to take them from there and use
>>> them
>>> > into
>>> > main/openssl with minor adaptions.
>>>
>>> That would fix only part of the problem.  The other part of the problem
>>> is that the version of openssl that we currently bundle doesn't
>>> implement the newer and more secure protocols and ciphers.  The older
>>> and less secure ones are gradually getting disabled on the server side.
>>>
>>> For instance, my only copy of Windows is XP, and the last version of IE
>>> released for XP can no longer connect to some web sites because they
>>> have disabled all of the protocols that IE supports.
>>>
>>
>> That is a valid concern, however I am unsure about what in OpenOffice
>> uses the new cyphers. I think OpenSSL is used for signing documents:
>> when we update OpenSSL will AOO automatically accept more signing
>> options? I would expect browsers will bring their own SSL
>> implementations.
>
> I don't know what OpenOffice uses it for, either, but I would expect
> that it also gets used for downloading extensions.  I hadn't even
> thought about signatures.  That's something I haven't exercised it at
> all.

Let's rather research where AOO uses openssl instead of guessing.

I find the use of openssl for document encryption and signing highly
unlikely, as NSS was used there to make use of Firefox's root CA
certificates, and allow configuring personal digital signatures using
the Firefox GUI.

So which modules use openssl?

$ grep openssl */prj/build.lst
oox/prj/build.lst:ooxoox : vos cppu cppuhelper comphelper sal
offapi sax basegfx xmlscript tools vcl BOOST:boost OPENSSL:openssl
LIBXSLT:libxslt NULL
openssl/prj/build.lst:ssl  openssl  :  soltools external EXPAT:expat NULL
openssl/prj/build.lst:ssl  openssl usr1   -   all
   ssl_mkout NULL
openssl/prj/build.lst:ssl  openssl nmake  -   all
   ssl_openssl NULL
python/prj/build.lst:pypython:SO:so_prereq solenv
OPENSSL:openssl NULL
redland/prj/build.lst:rld redland : stlport soltools
LIBXML2:libxml2 LIBXSLT:libxslt OPENSSL:openssl NULL
ucb/prj/build.lst:uc ucb : cppuhelper CURL:curl OPENSSL:openssl
LIBXML2:libxml2 LIBXSLT:libxslt offapi sal salhelper ucbhelper udkapi
comphelper SERF:serf tools NULL

Eliminating the openssl module itself from the above results, we have
dependencies to it in oox, python, redland, and ucb.

Oox (used for OOXML, not ODF) uses it in the short
lclCheckEncryptionData() function to detect encryption. It uses it
exclusively for AES crypto.

Python could use it for just about anything, but we don't care because
Python is itself optional.

Redland is an RDF library. It is used by unoxml. Not sure for what.

Ucb apparently uses it for webdav. It doesn't call openssl APIs, but
links to openssl because it uses serf.

Serf needs openssl and is only used by ucb.

Damjan

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

RE: Release Manager for 4.2.0?

[Dennis E. Hamilton]

> -Original Message-
> From: Don Lewis [mailto:truck...@apache.org]
> Sent: Monday, March 28, 2016 15:32
> To: dev@openoffice.apache.org
> Cc: dennis.hamil...@acm.org
> Subject: Re: Release Manager for 4.2.0?
> 
> On 28 Mar, Dennis E. Hamilton wrote:
> > Commenting just on document signing ...
> >
> >> -Original Message-
> >> From: Pedro Giffuni [mailto:p...@apache.org]
> >> Sent: Monday, March 28, 2016 13:48
> >> To: OOo Apache <dev@openoffice.apache.org>
> >> Subject: Re: Release Manager for 4.2.0?
> > [ ... ]
> >>
> >> [ ... ] I am unsure about what in OpenOffice
> >> uses the new cyphers. I think OpenSSL is used for signing documents:
> >> when we update OpenSSL will AOO automatically accept more signing
> >> options? I would expect browsers will bring their own SSL
> >> implementations.
> > [orcmid]
> >
> > The document signature support in Apache OpenOffice is based on XML
> > Digital Signatures Second Edition,
> > <http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/>. This has
> > nothing to do with communications via secure sockets of course.
> > Granted that OpenSSL provides library functions for more than that,
> > there is still very limited use for signing documents.
> >
> > X.509 digital certificates are employed.  XadES extensions may be used
> > (impacting metadata information mainly and only implemented by
> > Microsoft in ODF as far as I know).  Depending on the platform the
> > operating-system secure store for the signing key will usually be
> > employed, so there is operating-system integration.  (This is
> > definitely true for Windows.)
> 
> OpenSSL also provides libcrypto which contains functions for creating,
> validating, and using certificates.  It uses some of this functionality
> to verify that a secure socket connection is actually connected to the
> desired remote endpoint.  I've used to the openssl command line tool to
> produce a certificate that was used to authenticate a connection from a
> local application to a remote service.
> 
> There seems to be a standard place to store certificates under a user's
> home directory in the *nix world.  A while back I signed up for a
> service that requires updates from me to be signed with a certificate
> that they created for me and that my browser downloaded and stashed away
> somewhere.  When I tried signing a document with OpenOffice, it found
> this certificate and offered it as a choice for signing.
> 
> Since OpenOffice also uses curl, which is used for downloading files,
> and curl uses OpenSSL, it looks like OpenOffice depends on OpenSSL for
> secure downloads.  I don't know if it downloads anything other than
> extensions and updates.
[orcmid] 

That's useful to know.

Apache OpenOffice doesn't generate any client-side certificates, but it does 
use certs it can find for signing documents.  

I suspect, for secure downloads, AOO only works with the cert from the server, 
HTTPS-style.
> 
> 
> 
> 
> 
> -
> 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: Release Manager for 4.2.0?

[Don Lewis]

On 28 Mar, Kay Schenk wrote:
> 
> 
> On 03/27/2016 03:37 PM, Don Lewis wrote:
>> On 27 Mar, Andrea Pescetti wrote:
>>> On 29/01/2016 Andrea Pescetti wrote:
 For 4.2.0 we need a Release Manager. I would prefer NOT to be the
 Release Manager for 4.2.0 since I'm finding that in this period I can
 help more productively with tasks that do not require constant
 interaction ...
 I am surely available to have a significant role in the 4.2.0 release
>>>
>>> A few days after writing this, almost 2 months ago, sudden events left 
>>> me incapacitated to make any significant contributions until very 
>>> recently. I'm still unable to make long-term commitments.
>>>
>>> Anyway, there are some issues we need to get done as a team before 
>>> appointing a release manager makes sense:
>>>
>>> 1) Enough code. Done. The merge of the recent gbuild work totally 
>>> justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny 
>>> fraction of the fixes that (at that time) were available on trunk. So 
>>> here we are already OK, and we've been OK for months.
>> 
>> Some of the external software that is bundled has security issues.  I
>> put together a patch for nss here:
>> .
>> 
>> The version of libxml currently bundled also has a lot of known
>> vulnerabilities.  I'm currently testing a patch.
>> 
>> These both need review and testing.
> 
> Ok, I'll keep my eyes open for the libxml patch and test
> with your already supplied nss patch.

I filed a PR with the libxml patch late yesterday:


As an added bonus, here is the curl patch:



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

Re: Release Manager for 4.2.0?

[Kay Schenk]

On 03/27/2016 03:37 PM, Don Lewis wrote:
> On 27 Mar, Andrea Pescetti wrote:
>> On 29/01/2016 Andrea Pescetti wrote:
>>> For 4.2.0 we need a Release Manager. I would prefer NOT to be the
>>> Release Manager for 4.2.0 since I'm finding that in this period I can
>>> help more productively with tasks that do not require constant
>>> interaction ...
>>> I am surely available to have a significant role in the 4.2.0 release
>>
>> A few days after writing this, almost 2 months ago, sudden events left 
>> me incapacitated to make any significant contributions until very 
>> recently. I'm still unable to make long-term commitments.
>>
>> Anyway, there are some issues we need to get done as a team before 
>> appointing a release manager makes sense:
>>
>> 1) Enough code. Done. The merge of the recent gbuild work totally 
>> justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny 
>> fraction of the fixes that (at that time) were available on trunk. So 
>> here we are already OK, and we've been OK for months.
> 
> Some of the external software that is bundled has security issues.  I
> put together a patch for nss here:
> .
> 
> The version of libxml currently bundled also has a lot of known
> vulnerabilities.  I'm currently testing a patch.
> 
> These both need review and testing.

Ok, I'll keep my eyes open for the libxml patch and test
with your already supplied nss patch.


> 
> The versions of openssl and curl badly need updating for the same
> reason, and there is one CVE for serf.
> 
> There is a CVE for raptor-1.4.18, but I believe there was a cherry
> picked patch commited for that.
> 
> There are likely to be vulnerabilites in the bundled version of
> silgraphite, but it has been unmaintained upstream for quite some time.
> Ideally we would switch to Graphite2, but the API is radically different
> and this looks difficult.  The unattractive alternative is to look at
> the additional sanity checks added in recent Graphite2 commits and try
> to retrofit those into silgraphite.
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 

-- 

MzK

"Time spent with cats is never wasted."
   -- Sigmund Freud

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

Re: Release Manager for 4.2.0?

[Don Lewis]

On 28 Mar, Dennis E. Hamilton wrote:
> Commenting just on document signing ...
> 
>> -Original Message-
>> From: Pedro Giffuni [mailto:p...@apache.org]
>> Sent: Monday, March 28, 2016 13:48
>> To: OOo Apache <dev@openoffice.apache.org>
>> Subject: Re: Release Manager for 4.2.0?
> [ ... ]
>> 
>> [ ... ] I am unsure about what in OpenOffice
>> uses the new cyphers. I think OpenSSL is used for signing documents:
>> when we update OpenSSL will AOO automatically accept more signing
>> options? I would expect browsers will bring their own SSL
>> implementations.
> [orcmid] 
> 
> The document signature support in Apache OpenOffice is based on XML
> Digital Signatures Second Edition,
> <http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/>. This has
> nothing to do with communications via secure sockets of course. 
> Granted that OpenSSL provides library functions for more than that,
> there is still very limited use for signing documents.
> 
> X.509 digital certificates are employed.  XadES extensions may be used
> (impacting metadata information mainly and only implemented by
> Microsoft in ODF as far as I know).  Depending on the platform the
> operating-system secure store for the signing key will usually be
> employed, so there is operating-system integration.  (This is
> definitely true for Windows.)

OpenSSL also provides libcrypto which contains functions for creating,
validating, and using certificates.  It uses some of this functionality
to verify that a secure socket connection is actually connected to the
desired remote endpoint.  I've used to the openssl command line tool to
produce a certificate that was used to authenticate a connection from a
local application to a remote service.

There seems to be a standard place to store certificates under a user's
home directory in the *nix world.  A while back I signed up for a
service that requires updates from me to be signed with a certificate
that they created for me and that my browser downloaded and stashed away
somewhere.  When I tried signing a document with OpenOffice, it found
this certificate and offered it as a choice for signing.

Since OpenOffice also uses curl, which is used for downloading files,
and curl uses OpenSSL, it looks like OpenOffice depends on OpenSSL for
secure downloads.  I don't know if it downloads anything other than
extensions and updates.





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

RE: Release Manager for 4.2.0?

[Dennis E. Hamilton]

Commenting just on document signing ...

> -Original Message-
> From: Pedro Giffuni [mailto:p...@apache.org]
> Sent: Monday, March 28, 2016 13:48
> To: OOo Apache <dev@openoffice.apache.org>
> Subject: Re: Release Manager for 4.2.0?
[ ... ]
> 
> [ ... ] I am unsure about what in OpenOffice
> uses the new cyphers. I think OpenSSL is used for signing documents:
> when we update OpenSSL will AOO automatically accept more signing
> options? I would expect browsers will bring their own SSL
> implementations.
[orcmid] 

The document signature support in Apache OpenOffice is based on XML Digital 
Signatures Second Edition, 
<http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/>. This has nothing to do 
with communications via secure sockets of course.  Granted that OpenSSL 
provides library functions for more than that, there is still very limited use 
for signing documents.

X.509 digital certificates are employed.  XadES extensions may be used 
(impacting metadata information mainly and only implemented by Microsoft in ODF 
as far as I know).  Depending on the platform the operating-system secure store 
for the signing key will usually be employed, so there is operating-system 
integration.  (This is definitely true for Windows.)

Basically, SHA-1 digests of each part within the ODF package (a Zip) are 
incorporated in the signature file in a  element.  That element is 
effectively what is signed using method RSA-SHA1.  The  element 
provides the encrypted details by which the  can be verified.  This 
information can be decrypted and checked using the public key certificate of 
the signer that is included in the signature file.  (These certificates have 
their own cryptographic verification.)

There are no other methods for the signature data and its signing.

PS. The encryption of ODF files is very different and independent of the 
signature mechanism.  It is password-based and it uses Blowfish 8-bit CFB mode 
by default, encrypting each part of the ODF package separately.  Signing of 
encrypted files is done after encryption.  There is an optional AES-256 usage 
as well.  That is not produced by Apache OpenOffice.  


> 
> TBH, when I updated OpenSSL in AOO, I intentionally didn't upgrade it
> further because the newer versions have more code but also more
> vulnerabilities, therefore the expected maintenance cost would be
> higher.  The FreeBSD 9.x updates are only a temporary workaround.
> Now that upstream is not maintaining the older 0.9.8 version
> it probably makes sense to reconsider upgrading.
> 
> Pedro.
> 
> 
> -
> 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: Release Manager for 4.2.0?

[Don Lewis]

On 28 Mar, Pedro Giffuni wrote:
> Hi Don;
> 
>> On 28 Mar, Pedro Giffuni wrote:
>> > In reply to Don,
>>
>> >> The versions of openssl and curl badly need updating for the same
>> >> reason, and there is one CVE for serf.
>> >
>> > FreeBSD casually keeps some backported updates for the same openssl
>> > version AOO uses:
>> >
>> > https://svnweb.freebsd.org/base/stable/9/crypto/openssl/?view=log
>> >
>> > It should be pretty straightforward to take them from there and use 
>> them
>> > into
>> > main/openssl with minor adaptions.
>>
>> That would fix only part of the problem.  The other part of the problem
>> is that the version of openssl that we currently bundle doesn't
>> implement the newer and more secure protocols and ciphers.  The older
>> and less secure ones are gradually getting disabled on the server side.
>>
>> For instance, my only copy of Windows is XP, and the last version of IE
>> released for XP can no longer connect to some web sites because they
>> have disabled all of the protocols that IE supports.
>>
> 
> That is a valid concern, however I am unsure about what in OpenOffice
> uses the new cyphers. I think OpenSSL is used for signing documents:
> when we update OpenSSL will AOO automatically accept more signing
> options? I would expect browsers will bring their own SSL
> implementations.

I don't know what OpenOffice uses it for, either, but I would expect
that it also gets used for downloading extensions.  I hadn't even
thought about signatures.  That's something I haven't exercised it at
all.

> TBH, when I updated OpenSSL in AOO, I intentionally didn't upgrade it
> further because the newer versions have more code but also more
> vulnerabilities, therefore the expected maintenance cost would be
> higher.  The FreeBSD 9.x updates are only a temporary workaround.
> Now that upstream is not maintaining the older 0.9.8 version
> it probably makes sense to reconsider upgrading.

And using FreeBSD 9.x as a patch source will not work past the end of
this year because of the FreeBSD 9 EOL.

The FreeBSD OpenOffice port uses --with-system-openssl, and when I build
it for my own use, I set WITH_OPENSSL_PORT=yes, so I am always using the
latest and greatest openssl release.  I haven't run into any problems
with it.  I just signed a document with it ;-)



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

Re: Release Manager for 4.2.0?

[Pedro Giffuni]

Hi Don;


On 28 Mar, Pedro Giffuni wrote:
> In reply to Don,

>> The versions of openssl and curl badly need updating for the same
>> reason, and there is one CVE for serf.
>
> FreeBSD casually keeps some backported updates for the same openssl
> version AOO uses:
>
> https://svnweb.freebsd.org/base/stable/9/crypto/openssl/?view=log
>
> It should be pretty straightforward to take them from there and use 
them

> into
> main/openssl with minor adaptions.

That would fix only part of the problem.  The other part of the problem
is that the version of openssl that we currently bundle doesn't
implement the newer and more secure protocols and ciphers.  The older
and less secure ones are gradually getting disabled on the server side.

For instance, my only copy of Windows is XP, and the last version of IE
released for XP can no longer connect to some web sites because they
have disabled all of the protocols that IE supports.



That is a valid concern, however I am unsure about what in OpenOffice
uses the new cyphers. I think OpenSSL is used for signing documents:
when we update OpenSSL will AOO automatically accept more signing
options? I would expect browsers will bring their own SSL
implementations.

TBH, when I updated OpenSSL in AOO, I intentionally didn't upgrade it
further because the newer versions have more code but also more
vulnerabilities, therefore the expected maintenance cost would be
higher.  The FreeBSD 9.x updates are only a temporary workaround.
Now that upstream is not maintaining the older 0.9.8 version
it probably makes sense to reconsider upgrading.

Pedro.


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

Re: Release Manager for 4.2.0?

[Don Lewis]

On 28 Mar, Pedro Giffuni wrote:
> In reply to Don,

>> The versions of openssl and curl badly need updating for the same
>> reason, and there is one CVE for serf.
> 
> FreeBSD casually keeps some backported updates for the same openssl 
> version AOO uses:
> 
> https://svnweb.freebsd.org/base/stable/9/crypto/openssl/?view=log
> 
> It should be pretty straightforward to take them from there and use them 
> into
> main/openssl with minor adaptions.

That would fix only part of the problem.  The other part of the problem
is that the version of openssl that we currently bundle doesn't
implement the newer and more secure protocols and ciphers.  The older
and less secure ones are gradually getting disabled on the server side.

For instance, my only copy of Windows is XP, and the last version of IE
released for XP can no longer connect to some web sites because they
have disabled all of the protocols that IE supports.


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

Re: Release Manager for 4.2.0?

[Pedro Giffuni]

In reply to Don,

FWIW, On the topic of updates
...

Some of the external software that is bundled has security issues.  I
put together a patch for nss here:
.

The version of libxml currently bundled also has a lot of known
vulnerabilities.  I'm currently testing a patch.

These both need review and testing.

The versions of openssl and curl badly need updating for the same
reason, and there is one CVE for serf.


FreeBSD casually keeps some backported updates for the same openssl 
version AOO uses:


https://svnweb.freebsd.org/base/stable/9/crypto/openssl/?view=log

It should be pretty straightforward to take them from there and use them 
into

main/openssl with minor adaptions.

Pedro.

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

RE: Release Manager for 4.2.0?

[Dennis E. Hamilton]

Great news!

Thanks, Andrea

> -Original Message-
> From: Andrea Pescetti [mailto:pesce...@apache.org]
> Sent: Sunday, March 27, 2016 13:13
> To: dev@openoffice.apache.org
> Subject: Re: Release Manager for 4.2.0?
> 
> On 29/01/2016 Andrea Pescetti wrote:
> > For 4.2.0 we need a Release Manager. I would prefer NOT to be the
> > Release Manager for 4.2.0 since I'm finding that in this period I can
> > help more productively with tasks that do not require constant
> > interaction ...
> > I am surely available to have a significant role in the 4.2.0 release
> 
> A few days after writing this, almost 2 months ago, sudden events left
> me incapacitated to make any significant contributions until very
> recently. I'm still unable to make long-term commitments.
> 
> Anyway, there are some issues we need to get done as a team before
> appointing a release manager makes sense:
> 
> 1) Enough code. Done. The merge of the recent gbuild work totally
> justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny
> fraction of the fixes that (at that time) were available on trunk. So
> here we are already OK, and we've been OK for months.
> 
> 2) Localization. I got shell access to the Pootle server a few days ago.
> I'm still looking around, and if someone else want to join this is an
> important part. We need to have a solid process for updating
> translations (the full route: new strings in code -> Pootle -> back to
> code -> in localized builds) in place.
> 
> 3) Buildbots and ASF-owned build machines. Buildbots are not essential
> for a release: 4.1.2 was built (like all previous releases in history)
> on non-ASF hardware; even if we build 4.2.0 on ASF-owned hardware, we
> can't use buildbots for it; we need to setup new systems. Those who read
> the infrastructure@ list can see the discussion I started there
> yesterday. Still, having buildbots helps QA and having ASF-owned build
> machines is an important investment for the project: at that point we
> will be able to make a release within days, not months. We should make
> as much progress as we can here. Again, if anybody can help, this is an
> important area.
> 
> 4) There are several optimizations I have in mind, especially on
> reducing a bit our binary size on Linux (trust me, it is really a pain
> to commit all those binaries to SVN, or to any version control system).
> But they are not essential.
> 
> I have just committed to the devtools/ area the scripts we (mainly
> Juergen) used to build the 4.1.2 release, with specs of the build
> machines. I've had them since last October, but I never committed them.
> They are a first step if we want to build our release binaries on ASF
> hardware: they contain build options and config.log to have some more
> information on the environment.
> 
> My next priorities will be localization (especially, re-exporting the
> Italian translation to Pootle and re-importing it) and and a
> proof-of-concept VM for building releases on Linux (64 bit) based on the
> above scripts. There is plenty of room for other to jump in (Linux 32,
> Windows, Mac; or localization management) so please do!
> 
> 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: Release Manager for 4.2.0?

[Andrea Pescetti]

On 29/01/2016 Andrea Pescetti wrote:

For 4.2.0 we need a Release Manager. I would prefer NOT to be the
Release Manager for 4.2.0 since I'm finding that in this period I can
help more productively with tasks that do not require constant
interaction ...
I am surely available to have a significant role in the 4.2.0 release


A few days after writing this, almost 2 months ago, sudden events left 
me incapacitated to make any significant contributions until very 
recently. I'm still unable to make long-term commitments.


Anyway, there are some issues we need to get done as a team before 
appointing a release manager makes sense:


1) Enough code. Done. The merge of the recent gbuild work totally 
justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny 
fraction of the fixes that (at that time) were available on trunk. So 
here we are already OK, and we've been OK for months.


2) Localization. I got shell access to the Pootle server a few days ago. 
I'm still looking around, and if someone else want to join this is an 
important part. We need to have a solid process for updating 
translations (the full route: new strings in code -> Pootle -> back to 
code -> in localized builds) in place.


3) Buildbots and ASF-owned build machines. Buildbots are not essential 
for a release: 4.1.2 was built (like all previous releases in history) 
on non-ASF hardware; even if we build 4.2.0 on ASF-owned hardware, we 
can't use buildbots for it; we need to setup new systems. Those who read 
the infrastructure@ list can see the discussion I started there 
yesterday. Still, having buildbots helps QA and having ASF-owned build 
machines is an important investment for the project: at that point we 
will be able to make a release within days, not months. We should make 
as much progress as we can here. Again, if anybody can help, this is an 
important area.


4) There are several optimizations I have in mind, especially on 
reducing a bit our binary size on Linux (trust me, it is really a pain 
to commit all those binaries to SVN, or to any version control system). 
But they are not essential.


I have just committed to the devtools/ area the scripts we (mainly 
Juergen) used to build the 4.1.2 release, with specs of the build 
machines. I've had them since last October, but I never committed them. 
They are a first step if we want to build our release binaries on ASF 
hardware: they contain build options and config.log to have some more 
information on the environment.


My next priorities will be localization (especially, re-exporting the 
Italian translation to Pootle and re-importing it) and and a 
proof-of-concept VM for building releases on Linux (64 bit) based on the 
above scripts. There is plenty of room for other to jump in (Linux 32, 
Windows, Mac; or localization management) so please do!


Regards,
  Andrea.

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