date:20171203

Patricia Shanahan  has asked  for 4.1.5_release_blocker:
Issue 127581: Writer crashes after copying all content
https://bz.apache.org/ooo/show_bug.cgi?id=127581

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

Re: 4.2.0: Baseline CentOS6 as reference build platform

2017-12-03 Thread Damjan Jovanovic

Sorry what I meant to say was, those flags to ./configure still let you
build with Gnome VFS instead of GIO.

I didn't take GIO out of the build, I just switched the default VFS
implementation from Gnome VFS to GIO.

Damjan

On Sun, Dec 3, 2017 at 4:28 PM, Jim Jagielski  wrote:

>
> > On Dec 3, 2017, at 1:16 AM, Damjan Jovanovic  wrote:
> >
> > On Sun, Dec 3, 2017 at 2:25 AM, Jim Jagielski  wrote:
> >
> >>
> >>> On Dec 2, 2017, at 5:56 PM, Andrea Pescetti 
> wrote:
> >>>
> >>> On 30/11/2017 Jim Jagielski wrote:
>  I think for 4.2.x and later, we have deprecated CentOS5 as a supported
>  build system... I ran into a LOT of issues.
> >>>
> >>> Such as, for example?
> >>
> >> for starters:
> >>  o zip 3.0.
> >>  o GIO
> >>
> >>
> > If you *really* need GIO, try adding --disable-gio --enable-gnome-vfs to
> > ./configure.
> >
>
> The issue is that CentOS5 simply does not and can not provide GIO.
> So it is, IMO at least, unsuitable for our reference community
> build platform.
>
> This was brought up on the "AOO 4.2.0-dev builds" thread.

Re: Updating the build guide (Re: a more sane way to override optimization flags in gbuild)

2017-12-03 Thread Keith N. McKenna

On 12/3/2017 3:30 PM, Jim Jagielski wrote:
> 
>> On Dec 3, 2017, at 1:31 PM, Andrea Pescetti  wrote:
>>
>> Keith N. McKenna wrote:
>>> That begs the Question should we add a section to the overall build
>>> guide for CentOS6? If yes I can add the section as a clone of the
>>> CentOS5 Guide with all the proper warnings and notes about it needing
>>> updating for the CentOS6 specifics.
>>
>> No, this wouldn't be helpful since the CentOS 6 guide should be almost 
>> completely different from the CentOS 5 one (that section is meant to only 
>> contain the distribution-specific details, and they differ significantly 
>> between major versions of the same distribution). So this is best done by 
>> someone who actually did build on CentOS 6.
>>
> 
> Actually, as someone who has built on both, the instructions are
> pretty much mirrors. In fact, a simple s/5/6/p almost does it :)
> 
> My plan is to edit 
> https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step
>  
> 
> and make the CentOS5 section AOO 4.1.x specific and, similar to what
> I did with the macOS guide, create a new CentOS6 section for 4.2.x and
> later.
> 
> 
Jim;
I am not a Linux user, but I am very familiar with the mwiki. Any help I
can be all you have to do is ask.

Regards
Keith




signature.asc
Description: OpenPGP digital signature

Re: [PROPOSAL] Public Beta for 4.2


Am 03.12.2017 um 22:54 schrieb Jim Jagielski:



On Dec 3, 2017, at 4:25 PM, Peter kovacs  wrote:

How do we then distinguish one beta build from another? By Build number? We 
need to track build versions.


Agreed... Right now we have:

RSCVERSION=420
RSCREVISION=420m1(Build:9800)
BUILD=9800
LAST_MINOR=m1
SOURCEVERSION=AOO420

We could bump BUILD and LAST_MINOR for each Beta, which
messes up our release numbering, or maybe we use
something like

RSCVERSION=420
RSCREVISION=420b1(Build:9800)
BUILD=9800
LAST_MINOR=b1
SOURCEVERSION=AOO420

for betas and then switch back to 'm1.. m2...' for the RCs.


at least the download scripting is knowing a beta release and is 
prepared. *)


Example:

// Beta Release: General properties.
DL_BETA.VERSION = "4.2.0-Beta1";
DL_BETA.NAME= "4.2.0 Beta1";
DL_BETA.MILESTONE   = "AOO420m1";
DL_BETA.BUILD   = "1234";
DL_BETA.SVN_REV = "r1234567";
DL_BETA.REL_DATE= "2017-Dec-XX";

So, a typical filename could be:
Apache_OpenOffice_4.2.0-Beta1_Linux_x86-64_install-rpm_en-US.tar.gz

*)
At least the scriping has parts to process to handle special steps and 
areas fot a beta release. However, of course it need to be tested and 
likely to be adapted. But don't worry I will take care ot this.


Marcus




If the vote is the only bad things we could use following flow:
The last voted RC does not have to be the last beta RC. We have special beta 
splash screens. Maybe an warning in about.
When the quality of the release is production ready we close the beta, remove 
all beta specials and build a last production version and that will be voted on.

By this we have simple names, every one can follow, plus we do not break our 
work process.

All the best
Peter

Am 3. Dezember 2017 18:40:23 MEZ schrieb Jim Jagielski :



On Dec 3, 2017, at 10:06 AM, Patricia Shanahan  wrote:

On 12/3/2017 6:50 AM, Marcus wrote:

Am 03.12.2017 um 11:11 schrieb Peter Kovacs:

I would put Beta into the Splash screen, but Release I would use RC

for for Release Candidate plus a number. So the first version would be
4.2.0RC1


If this does not break something of course.

I think this wouldn't be suitable. As soon as we have the last RC

which get approved, it is automatically the final release build. But a
RC in names and graphics is not what we want.

And doing a new build without the RC stuff cannot be done as it is

not what we had voted for.

The max we could do is to use RC in the filenames. Then we need

maybe just a rename and we have the final build. In the worst case it's
just a new upload with the same binary files but then with correct
filenames.

Marcus


I am opposed even to changing file names. Anything we do between the

final testing and uploading to SourceForge is a risk of something going
wrong with the process at a point where it can affect millions.




FWIW, I agree. This part of the process works well enough, I think,
and any "improvements" are likely not worth the risks.



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

Re: [PROPOSAL] Public Beta for 4.2

2017-12-03 Thread Patricia Shanahan


I agree with the flow in the second paragraph.

As an additional note, betas are not releases, and will be described as 
being experimental. We can make up any process we like for deciding to 
make one available to beta testers.


When we think we have a production-ready beta, and build a release 
candidate derived from it, we have to follow the Apache release vote 
process, including at least three PMC members doing builds on machines 
we control etc.


On 12/3/2017 1:25 PM, Peter kovacs wrote:

How do we then distinguish one beta build from another? By Build number? We 
need to track build versions.

If the vote is the only bad things we could use following flow:
The last voted RC does not have to be the last beta RC. We have special beta 
splash screens. Maybe an warning in about.
When the quality of the release is production ready we close the beta, remove 
all beta specials and build a last production version and that will be voted on.

By this we have simple names, every one can follow, plus we do not break our 
work process.

All the best
Peter

Am 3. Dezember 2017 18:40:23 MEZ schrieb Jim Jagielski :



On Dec 3, 2017, at 10:06 AM, Patricia Shanahan  wrote:

On 12/3/2017 6:50 AM, Marcus wrote:

Am 03.12.2017 um 11:11 schrieb Peter Kovacs:

I would put Beta into the Splash screen, but Release I would use RC

for for Release Candidate plus a number. So the first version would be
4.2.0RC1


If this does not break something of course.

I think this wouldn't be suitable. As soon as we have the last RC

which get approved, it is automatically the final release build. But a
RC in names and graphics is not what we want.

And doing a new build without the RC stuff cannot be done as it is

not what we had voted for.

The max we could do is to use RC in the filenames. Then we need

maybe just a rename and we have the final build. In the worst case it's
just a new upload with the same binary files but then with correct
filenames.

Marcus


I am opposed even to changing file names. Anything we do between the

final testing and uploading to SourceForge is a risk of something going
wrong with the process at a point where it can affect millions.




FWIW, I agree. This part of the process works well enough, I think,
and any "improvements" are likely not worth the risks.


-
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

Re: [PROPOSAL] Public Beta for 4.2


> On Dec 3, 2017, at 4:25 PM, Peter kovacs  wrote:
> 
> How do we then distinguish one beta build from another? By Build number? We 
> need to track build versions.

Agreed... Right now we have:

RSCVERSION=420
RSCREVISION=420m1(Build:9800)
BUILD=9800
LAST_MINOR=m1
SOURCEVERSION=AOO420

We could bump BUILD and LAST_MINOR for each Beta, which
messes up our release numbering, or maybe we use
something like

RSCVERSION=420
RSCREVISION=420b1(Build:9800)
BUILD=9800
LAST_MINOR=b1
SOURCEVERSION=AOO420

for betas and then switch back to 'm1.. m2...' for the RCs.

> 
> If the vote is the only bad things we could use following flow:
> The last voted RC does not have to be the last beta RC. We have special beta 
> splash screens. Maybe an warning in about.
> When the quality of the release is production ready we close the beta, remove 
> all beta specials and build a last production version and that will be voted 
> on.
> 
> By this we have simple names, every one can follow, plus we do not break our 
> work process.
> 
> All the best
> Peter
> 
> Am 3. Dezember 2017 18:40:23 MEZ schrieb Jim Jagielski :
>> 
>>> On Dec 3, 2017, at 10:06 AM, Patricia Shanahan  wrote:
>>> 
>>> On 12/3/2017 6:50 AM, Marcus wrote:
 Am 03.12.2017 um 11:11 schrieb Peter Kovacs:
> I would put Beta into the Splash screen, but Release I would use RC
>> for for Release Candidate plus a number. So the first version would be
>> 4.2.0RC1
> 
> If this does not break something of course.
 I think this wouldn't be suitable. As soon as we have the last RC
>> which get approved, it is automatically the final release build. But a
>> RC in names and graphics is not what we want.
 And doing a new build without the RC stuff cannot be done as it is
>> not what we had voted for.
 The max we could do is to use RC in the filenames. Then we need
>> maybe just a rename and we have the final build. In the worst case it's
>> just a new upload with the same binary files but then with correct
>> filenames.
 Marcus
>>> 
>>> I am opposed even to changing file names. Anything we do between the
>> final testing and uploading to SourceForge is a risk of something going
>> wrong with the process at a point where it can affect millions.
>>> 
>> 
>> FWIW, I agree. This part of the process works well enough, I think,
>> and any "improvements" are likely not worth the risks.
>> 
>> 
>> -
>> 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

Re: [PROPOSAL] Public Beta for 4.2

2017-12-03 Thread Peter kovacs

How do we then distinguish one beta build from another? By Build number? We 
need to track build versions.

If the vote is the only bad things we could use following flow:
The last voted RC does not have to be the last beta RC. We have special beta 
splash screens. Maybe an warning in about.
When the quality of the release is production ready we close the beta, remove 
all beta specials and build a last production version and that will be voted on.

By this we have simple names, every one can follow, plus we do not break our 
work process.

All the best
Peter

Am 3. Dezember 2017 18:40:23 MEZ schrieb Jim Jagielski :
>
>> On Dec 3, 2017, at 10:06 AM, Patricia Shanahan  wrote:
>> 
>> On 12/3/2017 6:50 AM, Marcus wrote:
>>> Am 03.12.2017 um 11:11 schrieb Peter Kovacs:
 I would put Beta into the Splash screen, but Release I would use RC
>for for Release Candidate plus a number. So the first version would be
>4.2.0RC1
 
 If this does not break something of course.
>>> I think this wouldn't be suitable. As soon as we have the last RC
>which get approved, it is automatically the final release build. But a
>RC in names and graphics is not what we want.
>>> And doing a new build without the RC stuff cannot be done as it is
>not what we had voted for.
>>> The max we could do is to use RC in the filenames. Then we need
>maybe just a rename and we have the final build. In the worst case it's
>just a new upload with the same binary files but then with correct
>filenames.
>>> Marcus
>> 
>> I am opposed even to changing file names. Anything we do between the
>final testing and uploading to SourceForge is a risk of something going
>wrong with the process at a point where it can affect millions.
>> 
>
>FWIW, I agree. This part of the process works well enough, I think,
>and any "improvements" are likely not worth the risks.
>
>
>-
>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

4.1.5_release_blocker requested: [Issue 127552] Update metadata for OpenOffice 4.1.5 release

Matthias Seidel  has asked  for 4.1.5_release_blocker:
Issue 127552: Update metadata for OpenOffice 4.1.5 release
https://bz.apache.org/ooo/show_bug.cgi?id=127552

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

4.1.5_release_blocker canceled: [Issue 127158] AOO-logo in Start Center looks misplaced

Matthias Seidel  has canceled Matthias Seidel
's request for 4.1.5_release_blocker:
Issue 127158: AOO-logo in Start Center looks misplaced
https://bz.apache.org/ooo/show_bug.cgi?id=127158

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

4.1.5_release_blocker requested: [Issue 127158] AOO-logo in Start Center looks misplaced

Matthias Seidel  has asked  for 4.1.5_release_blocker:
Issue 127158: AOO-logo in Start Center looks misplaced
https://bz.apache.org/ooo/show_bug.cgi?id=127158

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

Re: [PROPOSAL] Start process for AOO 4.1.5-RC1


Am 03.12.2017 um 21:57 schrieb Andrea Pescetti:

Jim Jagielski wrote:

I propose that we, "officially", start the ball
rolling in the process of releasing AOO 4.1.5.


Are you accepting blockers? My only blocker would be the English 
dictionary update https://bz.apache.org/ooo/show_bug.cgi?id=127621 (a 
new version is available and we don't want users to upgrade to 4.1.5 and 
receive a message telling them that they should upgrade again to get a 
newer dictionary).


We don't have a 4.1.5 blocker flag in Bugzilla, but I guess we can do 
without it if this is the only extra fix we will include - dictionary 
updates are routine. Of course, if the dictionary update is deemed not 
to be important we can skip it too.


thanks for the reminder. Now we have 4.1.5 blocker flag.

IMHO it's better than to work with exceptions that only live in mailing 
lists or in worst case only in our heads. ;-)


We have a process which was working good in the past, so let's use it. 
Then it's also easier to tracker the real changes and document them in 
the Release Notes.


Marcus


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

4.1.5_release_blocker granted: [Issue 127621] Update English dictionary to version 2017.11.01

Marcus  has granted  4.1.5_release_blocker:
Issue 127621: Update English dictionary to version 2017.11.01
https://bz.apache.org/ooo/show_bug.cgi?id=127621



--- Comment #1 from Marcus  ---
Set blocker flag and target milestone for 4.1.5

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

Re: [PROPOSAL] Start process for AOO 4.1.5-RC1

2017-12-03 Thread Matthias Seidel

Am 03.12.2017 um 21:33 schrieb Jim Jagielski:
> I propose that we, "officially", start the ball
> rolling in the process of releasing AOO 4.1.5.
>
> As such, I encourage people to follow and
> edit (as needed):
>
>https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.5
>
> with the goal of getting a 4.1.5-RC1 out "kinda soon" :)

Sounds good!

But before we think of an RC we must not forget this issue:

 - In openoffice.lst the update URL must point to 415:
   https://bz.apache.org/ooo/show_bug.cgi?id=127552#c3

Regards, Matthias

>
> -
> 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: [PROPOSAL] Public Beta for 4.2

2017-12-03 Thread Kay Schenk



On 12/02/2017 04:03 PM, Andrea Pescetti wrote:

On 01/12/2017 Jim Jagielski wrote:
I see that Pat has committed the security patches to trunk, which is 
fantastic!

Maybe we should take the next few business days and go thru Bugz
and see what, if anything, would be low-risk patches to trunk and
pencil in, say, Dec 7th as a "code freeze" date for builds...


Someone here is forgetting that the biggest chunk of work for 4.2.0 is 
with localization. We need to fix the code -> Pootle -> code process and 
this won't be trivial at all since we have scarce documentation, little 
knowledge and a half-broken situation in Pootle when the last import was 
done at some unspecified time. It is not impossible of course, but it 
does need some serious work.


+1...this is a BIGGIE for 4.2.0 in my mind.



So you can provide all the builds you wish, but I would expect that most 
of them display localization issues and a localization cycle in 40+ 
languages usually takes a couple months (once we have fixed the process).


I'm absolutely in favor of a public beta, well publicized and clearly 
marked as beta (with its own splash screen etc). This is not the point. 
Point is, if you want something out in 2017 then English+kid languages 
will be enough, and please call it Alpha or Beta-1 or something that 
makes it clear that there will have to be another Beta in a few months 
with working localized versions.


Regards,
   Andrea.

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



--
--
MzK

"Don't you know that it's worth
 every treasure on earth
 To be young at heart."
  -- song, "Young at Heart"

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

Re: [PROPOSAL] Start process for AOO 4.1.5-RC1


Jim Jagielski wrote:

I propose that we, "officially", start the ball
rolling in the process of releasing AOO 4.1.5.


Are you accepting blockers? My only blocker would be the English 
dictionary update https://bz.apache.org/ooo/show_bug.cgi?id=127621 (a 
new version is available and we don't want users to upgrade to 4.1.5 and 
receive a message telling them that they should upgrade again to get a 
newer dictionary).


We don't have a 4.1.5 blocker flag in Bugzilla, but I guess we can do 
without it if this is the only extra fix we will include - dictionary 
updates are routine. Of course, if the dictionary update is deemed not 
to be important we can skip it too.


Regards,
  Andrea.

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

Re: [PROPOSAL] Public Beta for 4.2

2017-12-03 Thread Matthias Seidel

Am 03.12.2017 um 01:09 schrieb Andrea Pescetti:
> Jim Jagielski wrote:
>> I went ahead and copied the 4.1.4 page and created:
>>  https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.5
>> Of course, it needs to be further cleaned up. I can RM if that's OK
>> with everyone.
>
> Fine with me, let's keep unchanged everything that worked well for
> 4.1.4! Note: this includes the fact that Matthias (if available)
> should produce the Windows builds, since we've discovered with 4.1.4
> that build issues are arcane to find at times, and we know that
> Matthias' Windows builds worked well for 4.1.4.

Yes, I am available... ;-)

Regards, Matthias

>
> 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

[PROPOSAL] Start process for AOO 4.1.5-RC1

I propose that we, "officially", start the ball
rolling in the process of releasing AOO 4.1.5.

As such, I encourage people to follow and
edit (as needed):

   https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.5

with the goal of getting a 4.1.5-RC1 out "kinda soon" :)

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

Re: Updating the build guide (Re: a more sane way to override optimization flags in gbuild)


> On Dec 3, 2017, at 1:31 PM, Andrea Pescetti  wrote:
> 
> Keith N. McKenna wrote:
>> That begs the Question should we add a section to the overall build
>> guide for CentOS6? If yes I can add the section as a clone of the
>> CentOS5 Guide with all the proper warnings and notes about it needing
>> updating for the CentOS6 specifics.
> 
> No, this wouldn't be helpful since the CentOS 6 guide should be almost 
> completely different from the CentOS 5 one (that section is meant to only 
> contain the distribution-specific details, and they differ significantly 
> between major versions of the same distribution). So this is best done by 
> someone who actually did build on CentOS 6.
> 

Actually, as someone who has built on both, the instructions are
pretty much mirrors. In fact, a simple s/5/6/p almost does it :)

My plan is to edit 
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step 

and make the CentOS5 section AOO 4.1.x specific and, similar to what
I did with the macOS guide, create a new CentOS6 section for 4.2.x and
later.

[NOMINATION] New Apache OpenOfice Chair

With the past October board meeting I'm the project Chair since 13 
months. So, when we follow our own (unwritten) rule to change the Chair 
every ~12 month, then it's again time to find a new one.


Therefore I'm asking for PMCs and committers to step up to become our 
new PMC Chair.


I want to follow this timeline to finish the vote process to make it in 
time for the December Board meeting on 20th Dec:


Nomination: now until 08th Dec
Vote: 08th until 15th Dec
Resolution for Board meeting: 16th Dec

What is it about?

The Chair is like the referee in a football game. He should keep an eye 
on everything, but go mostly unnoticed in doing so.


The primary task of a Chair is to report to the Board. On one side, this 
requires a constant monitoring of the project and some 
familiarity/experience with all aspects of OpenOffice as a project. On 
the other side, this requires patience, discovery of the processes to 
follow, reading some procedural documentation in English that is often 
full of Apache jargon or legal terminology.


The work itself is thus a bit boring and clerical. The typical paper 
work. Consider that the Chair will often be active in the project in 
some other way: he/she is still an ordinary committer after all, and the 
title does not make him/her special in the day-to-day activity. But a 
Chair will definitely have to allocate time for monitoring the various 
lists and staying informed about all ongoing issues. The most time 
consuming job is maybe the creation of the Board report every 3 months.


Or in other words:

It's not to represent officially the project to the outside. It's more 
an Apache internal job and even this is limited. For details please see 
here [1].


Now please speak up if you want to suggest someone - or maybe yourself - 
you want to see as the new Chair.


[1] https://www.apache.org/dev/pmc.html#chair

Thanks in advance for your participation.

Marcus

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

Re: [PROPOSAL] Public Beta for 4.2


Am 01.12.2017 um 22:51 schrieb Jim Jagielski:

I went ahead and copied the 4.1.4 page and created:

 https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.5 


Of course, it needs to be further cleaned up.


thanks for this. In the meantime I've also done some changes.


I can RM if that's OK with everyone.


Yes, please. :-)

Marcus




On Dec 1, 2017, at 4:37 PM, Keith N. McKenna  wrote:

On 12/1/2017 8:18 AM, Patricia Shanahan wrote:

Remember we also have the 4.1.5 branch, which is a lower risk solution
to some 4.1.4 regressions.

I think it is time to decide whether to release it, and if so, what the
timing should be relative to the start of the 4.2 beta test. There is
something to be said for a single announcement so that we can explain
the relationship.

On 12/1/2017 5:13 AM, Jim Jagielski wrote:

I see that Pat has committed the security patches to trunk, which is
fantastic!
Maybe we should take the next few business days and go thru Bugz
and see what, if anything, would be low-risk patches to trunk and
pencil in, say, Dec 7th as a "code freeze" date for builds...

I can provide builds for all 4 platforms.


On Dec 1, 2017, at 1:34 AM, Mechtilde  wrote:

Hello

I like this idea, too. it makes it visible that we aren't dead.

Regards

Mechtilde

Am 01.12.2017 um 03:41 schrieb Jim Jagielski:

I like it. I already have Linux, Windows and macOS 4.2.0-dev builds
available
(http://home.apache.org/~jim/AOO-builds/
) for some langs



On Nov 30, 2017, at 5:15 PM, Marcus  wrote:

Am 30.11.2017 um 21:26 schrieb Dave Fisher:

In light of our current situation with getting builds together but
not having a lot of people doing more than simple QA what does the
team think about releasing a Public Beta for 4.2.0? I think that
this would be an advantage for the project and might serve to
bring in more of the community as QA volunteers.


I thought it's without discussion that we need a (long) beta test
phase for 4.2.0. So, yes for your proposal.

We can create a new entry on the download webpage, some advertising
areas on the other webpages, and other fine things to make it visible.

And - also this should be clear already - we need several builds of
4.2.0 with further included bugfixes; to show an increasing quality
towards the final release build.

For me the real question is " *When* do we start the beta? ". ;-) I
would like to have a specific level of quality that we give to our
users. Otherwise we will get spammed by bug reports which nobody
wants to handle.

Marcus


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






--
Mechtilde Stehmann
## Apache OpenOffice.org
## Freie Office Suite für Linux, MacOSX, Windows
## Debian Developer
## Loook, calender-exchange-provider, libreoffice-canzeley-client
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F




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


+1 to this. We need to get out the corrections for the 4.1.4 regressions
soon as possible.



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

Re: Tweet new build

2017-12-03 Thread Roberto Galoppini

2017-12-03 19:12 GMT+01:00 Andrea Pescetti :

> FR web forum wrote:
>
>> No news about 4.1.4 build.
>> Anybody to tweet this annoucement?
>> https://twitter.com/ openofficeorg
>>
>
> This is not the official OpenOffice Twitter account. The official account
> is
>
> https://twitter.com/apacheoo
>
> that is managed, as far as I know, by Roberto on behalf of the PMC. And of
> course it provided coverage of the 4.1.4 release.
>

I think it's co-managed, and I'll take the chance to ask if anyone else is
willing to join the team. In the specific case it has been just a RT of the
Apache's tweet.
Next time or when appropriate we can ship it beofre anyone else and let
others RT, though.

Roberto


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

Updating the build guide (Re: a more sane way to override optimization flags in gbuild)


Keith N. McKenna wrote:

That begs the Question should we add a section to the overall build
guide for CentOS6? If yes I can add the section as a clone of the
CentOS5 Guide with all the proper warnings and notes about it needing
updating for the CentOS6 specifics.


No, this wouldn't be helpful since the CentOS 6 guide should be almost 
completely different from the CentOS 5 one (that section is meant to 
only contain the distribution-specific details, and they differ 
significantly between major versions of the same distribution). So this 
is best done by someone who actually did build on CentOS 6.



Also will the top level build guide at
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO need
updating?


Not major changes at least. It might need some minor updates, but the 
process didn't change much. Still, since we do not provide a detailed 
README with build instructions in the sources, it will be important to 
make sure the page still applies when we are closer to a release. Thanks 
for the heads-up.


Regards,
  Andrea.

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

Re: Tweet new build


FR web forum wrote:

No news about 4.1.4 build.
Anybody to tweet this annoucement?
https://twitter.com/ openofficeorg


This is not the official OpenOffice Twitter account. The official account is

https://twitter.com/apacheoo

that is managed, as far as I know, by Roberto on behalf of the PMC. And 
of course it provided coverage of the 4.1.4 release.


Regards,
  Andrea.

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

Re: A more sane way to build - SCons, deCygwination and other hopes


On 02/12/2017 Jim Jagielski wrote:

What I don't want is some hybrid monstrosity like we
have now. Nor do I want work on the build system to hold
off release of 4.2.0.


This is surely a good point. Actually, the wide delay between 4.1.0 and 
the future 4.2.0 is due in big part to build changes. Most welcome, but 
also time consuming.


There is a reason, though, that makes Damjan's current effort worth 
investigating in all cases: we had to put a large patch (for a bugfix 
involving work with remote files) on hold for 4.1.2 since that would 
have required updating serf, which in turn would have implied that we 
added support for SCons as they have switched to it for their recent 
releases. I can dig up the issue if you need, just ask if interested. 
Having a way to build SCons-based packages would already be a step 
forward. And yes, it would be "just another tool" in this case, but with 
so many dependencies we must be able to integrate many build systems.


Regards,
  Andrea.

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

Re: [PROPOSAL] Public Beta for 4.2


> On Dec 3, 2017, at 10:06 AM, Patricia Shanahan  wrote:
> 
> On 12/3/2017 6:50 AM, Marcus wrote:
>> Am 03.12.2017 um 11:11 schrieb Peter Kovacs:
>>> I would put Beta into the Splash screen, but Release I would use RC for for 
>>> Release Candidate plus a number. So the first version would be 4.2.0RC1
>>> 
>>> If this does not break something of course.
>> I think this wouldn't be suitable. As soon as we have the last RC which get 
>> approved, it is automatically the final release build. But a RC in names and 
>> graphics is not what we want.
>> And doing a new build without the RC stuff cannot be done as it is not what 
>> we had voted for.
>> The max we could do is to use RC in the filenames. Then we need maybe just a 
>> rename and we have the final build. In the worst case it's just a new upload 
>> with the same binary files but then with correct filenames.
>> Marcus
> 
> I am opposed even to changing file names. Anything we do between the final 
> testing and uploading to SourceForge is a risk of something going wrong with 
> the process at a point where it can affect millions.
> 

FWIW, I agree. This part of the process works well enough, I think,
and any "improvements" are likely not worth the risks.


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

Tweet new build

2017-12-03 Thread FR web forum

No news about 4.1.4 build.
Anybody to tweet this annoucement?
https://twitter.com/openofficeorg

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

Re: [PROPOSAL] Public Beta for 4.2

2017-12-03 Thread Patricia Shanahan


On 12/3/2017 6:50 AM, Marcus wrote:

Am 03.12.2017 um 11:11 schrieb Peter Kovacs:
I would put Beta into the Splash screen, but Release I would use RC 
for for Release Candidate plus a number. So the first version would be 
4.2.0RC1


If this does not break something of course.


I think this wouldn't be suitable. As soon as we have the last RC which 
get approved, it is automatically the final release build. But a RC in 
names and graphics is not what we want.


And doing a new build without the RC stuff cannot be done as it is not 
what we had voted for.


The max we could do is to use RC in the filenames. Then we need maybe 
just a rename and we have the final build. In the worst case it's just a 
new upload with the same binary files but then with correct filenames.


Marcus


I am opposed even to changing file names. Anything we do between the 
final testing and uploading to SourceForge is a risk of something going 
wrong with the process at a point where it can affect millions.


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

Re: [PROPOSAL] Public Beta for 4.2

Am 03.12.2017 um 11:11 schrieb Peter Kovacs:
I would put Beta into the Splash screen, but Release I would use RC for
for Release Candidate plus a number. So the first version would be 4.2.0RC1

If this does not break something of course.

I think this wouldn't be suitable. As soon as we have the last RC which
get approved, it is automatically the final release build. But a RC in
names and graphics is not what we want.

And doing a new build without the RC stuff cannot be done as it is not
what we had voted for.

The max we could do is to use RC in the filenames. Then we need maybe
just a rename and we have the final build. In the worst case it's just a
new upload with the same binary files but then with correct filenames.

Marcus

On 03.12.2017 10:14, Marcus wrote:

Am 02.12.2017 um 23:21 schrieb Jim Jagielski:
On Dec 2, 2017, at 8:39 AM, Marcus > wrote:

Am 02.12.2017 um 13:22 schrieb Matthias Seidel:
Despite of the name it could be the icon of the dmg file? I don't
know where this icon set is visible... ;-)

Apart from that: +1 for a public beta.
But we should build "real" beta builds, with the appropriate
naming/graphics:
https://home.apache.org/~mseidel/AOO-builds/AOO-420-Beta/About%20OpenOffice%20Beta%204.2.0.png

oh yes, good hint. IMHO the splash screen and start center graphic
should show clearly that this is a beta release. Plus different
filenames for the installation files.

Here are the results on macOS:

that looks great. On the start center it's a bit different. "beta"
should be aligned with the productname/version like for the splash
screen.

Marcus

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

4.2.0: Baseline CentOS6 as reference build platform


> On Dec 3, 2017, at 1:16 AM, Damjan Jovanovic  wrote:
> 
> On Sun, Dec 3, 2017 at 2:25 AM, Jim Jagielski  wrote:
> 
>> 
>>> On Dec 2, 2017, at 5:56 PM, Andrea Pescetti  wrote:
>>> 
>>> On 30/11/2017 Jim Jagielski wrote:
 I think for 4.2.x and later, we have deprecated CentOS5 as a supported
 build system... I ran into a LOT of issues.
>>> 
>>> Such as, for example?
>> 
>> for starters:
>>  o zip 3.0.
>>  o GIO
>> 
>> 
> If you *really* need GIO, try adding --disable-gio --enable-gnome-vfs to
> ./configure.
> 

The issue is that CentOS5 simply does not and can not provide GIO.
So it is, IMO at least, unsuitable for our reference community
build platform. 

This was brought up on the "AOO 4.2.0-dev builds" thread.

Re: [PROPOSAL] Public Beta for 4.2

2017-12-03 Thread Keith N. McKenna

On 12/1/2017 4:51 PM, Jim Jagielski wrote:
> I went ahead and copied the 4.1.4 page and created:
> 
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.5 
> 
> 
> Of course, it needs to be further cleaned up. I can RM if that's OK
> with everyone.
I have added the Release Notes page from the template at
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.5+Release+Notes.
I believe that you are the best person for RM for this.

Regards
Keith
> 
>> On Dec 1, 2017, at 4:37 PM, Keith N. McKenna  
>> wrote:
>>
>> On 12/1/2017 8:18 AM, Patricia Shanahan wrote:
>>> Remember we also have the 4.1.5 branch, which is a lower risk solution
>>> to some 4.1.4 regressions.
>>>
>>> I think it is time to decide whether to release it, and if so, what the
>>> timing should be relative to the start of the 4.2 beta test. There is
>>> something to be said for a single announcement so that we can explain
>>> the relationship.
>>>
>>> On 12/1/2017 5:13 AM, Jim Jagielski wrote:
 I see that Pat has committed the security patches to trunk, which is
 fantastic!
 Maybe we should take the next few business days and go thru Bugz
 and see what, if anything, would be low-risk patches to trunk and
 pencil in, say, Dec 7th as a "code freeze" date for builds...

 I can provide builds for all 4 platforms.

> On Dec 1, 2017, at 1:34 AM, Mechtilde  wrote:
>
> Hello
>
> I like this idea, too. it makes it visible that we aren't dead.
>
> Regards
>
> Mechtilde
>
> Am 01.12.2017 um 03:41 schrieb Jim Jagielski:
>> I like it. I already have Linux, Windows and macOS 4.2.0-dev builds
>> available
>> (http://home.apache.org/~jim/AOO-builds/
>> ) for some langs
>>
>>
>>> On Nov 30, 2017, at 5:15 PM, Marcus  wrote:
>>>
>>> Am 30.11.2017 um 21:26 schrieb Dave Fisher:
 In light of our current situation with getting builds together but
 not having a lot of people doing more than simple QA what does the
 team think about releasing a Public Beta for 4.2.0? I think that
 this would be an advantage for the project and might serve to
 bring in more of the community as QA volunteers.
>>>
>>> I thought it's without discussion that we need a (long) beta test
>>> phase for 4.2.0. So, yes for your proposal.
>>>
>>> We can create a new entry on the download webpage, some advertising
>>> areas on the other webpages, and other fine things to make it visible.
>>>
>>> And - also this should be clear already - we need several builds of
>>> 4.2.0 with further included bugfixes; to show an increasing quality
>>> towards the final release build.
>>>
>>> For me the real question is " *When* do we start the beta? ". ;-) I
>>> would like to have a specific level of quality that we give to our
>>> users. Otherwise we will get spammed by bug reports which nobody
>>> wants to handle.
>>>
>>> Marcus
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>
>>
>>
>
> -- 
> Mechtilde Stehmann
> ## Apache OpenOffice.org
> ## Freie Office Suite für Linux, MacOSX, Windows
> ## Debian Developer
> ## Loook, calender-exchange-provider, libreoffice-canzeley-client
> ## PGP encryption welcome
> ## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F
>


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

>> +1 to this. We need to get out the corrections for the 4.1.4 regressions
>> soon as possible.
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: a more sane way to override optimization flags in gbuild

2017-12-03 Thread Keith N. McKenna

On 12/3/2017 4:14 AM, Andrea Pescetti wrote:
> Jim Jagielski wrote:
>>> On Dec 2, 2017, at 5:56 PM, Andrea Pescetti wrote:
>>> On 30/11/2017 Jim Jagielski wrote:
 I think for 4.2.x and later, we have deprecated CentOS5 as a supported
 build system... I ran into a LOT of issues.
>>> Such as, for example?
>> for starters:
>>    o zip 3.0.
>>    o GIO
> 
> OK, I now get it. You ran into issues when you tried to build *trunk* on
> CentOS 5, not when you built 4.1.4 on CentOS 5. I had read your sentence
> above as "We should deprecate CentOS 5 since I found lots of issues
> [when building 4.1.4]".
> 
>> Isn't that exactly what I'm doing???
> 
> Yes, we are on the same page:
> 
> - The CentOS 5 guide works well and smoothly for 4.1.x
> 
> - The CentOS 5 guide does not work any longer for trunk (for the reasons
> Damjan detailed), but this is irrelevant as we'll update to CentOS 6
> anyway.
> 
> Regards,
>   Andrea.
That begs the Question should we add a section to the overall build
guide for CentOS6? If yes I can add the section as a clone of the
CentOS5 Guide with all the proper warnings and notes about it needing
updating for the CentOS6 specifics.

Also will the top level build guide at
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO need
updating?

Regards
Keith



signature.asc
Description: OpenPGP digital signature

Re: [PROPOSAL] Public Beta for 4.2

2017-12-03 Thread Peter Kovacs

I would put Beta into the Splash screen, but Release I would use RC for 
for Release Candidate plus a number. So the first version would be 4.2.0RC1


If this does not break something of course.

All the best
Peter

On 03.12.2017 10:14, Marcus wrote:

Am 02.12.2017 um 23:21 schrieb Jim Jagielski:
On Dec 2, 2017, at 8:39 AM, Marcus > wrote:


Am 02.12.2017 um 13:22 schrieb Matthias Seidel:
Despite of the name it could be the icon of the dmg file? I don't 
know where this icon set is visible... ;-)

Apart from that: +1 for a public beta.
But we should build "real" beta builds, with the appropriate 
naming/graphics:
https://home.apache.org/~mseidel/AOO-builds/AOO-420-Beta/About%20OpenOffice%20Beta%204.2.0.png 



oh yes, good hint. IMHO the splash screen and start center graphic 
should show clearly that this is a beta release. Plus different 
filenames for the installation files.




Here are the results on macOS:


that looks great. On the start center it's a bit different. "beta" 
should be aligned with the productname/version like for the splash 
screen.


Marcus


-
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: A more sane way to build - SCons, deCygwination and other hopes

2017-12-03 Thread Peter Kovacs




On 03.12.2017 01:57, Don Lewis wrote:

On  2 Dec, Damjan Jovanovic wrote:

* Nobody knows gbuild. The syntax is atrocious. It uses obscure features of
GNU make. We can't debug it. It takes days of work to investigate/fix any
problem with it, work that could be better spent on a this vast project
with few development resources.

Agreed 1000% here.

If you are doing a build with bundled python, how do you bootstrap?  If
you are on Windows and don't have python, how do you run the SCons
equivalent of configure and then use SCons to build python?

Today you need perl. So we replace one language with another.
I think the benefit is that Scons is a generic Buildsystem that is 
maintained by a team.
So creating a valid build environment may be much simpler then the 
version we have today.

But this depends how we use the tool.

Configure and bootstrap is up to us. We could stick with the current 
process. (Replace only the build command)
We could include the current process within Scons. Or we could integrate 
both into Scons using Scons provided tools.

While I am not sure how to do the last step.
What I have seen if we integrate it into Scon, we can define our own 
Flags to control the behaviour. (Switch Bootstrap on, or not)

And a more recent question near and dear to my heart, how easy is it to
do per-target optimization flag overrides?
Scons thinks in build Environments, which are Enviroment Objects. Each 
Environment contains build flags.


An Enviroment could Fetch Values from another enviroment, but we can 
also expand values, replace values or clone them. There are also ways to 
Append  and to Prepend values (with the option do do this unique).

An Environment can be created having default values.
We can define Issue handling on environment level. If we know 
combinations do not work or something is missing.


We can also define multiple Enviroments. However a build config can only 
be associated with one build environment.


I hope this gives an Idea what posilities we have with Scons. How we 
design our build process is up to us.
I would think that we have one global environment that feeds from 
Templates like Debug and release. Each Module has then a specific own 
Environment which feeds from the global ones.


HTH
Peter


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

Re: [PROPOSAL] Public Beta for 4.2

2017-12-03 Thread Matthias Seidel

Am 03.12.2017 um 10:14 schrieb Marcus:
> Am 02.12.2017 um 23:21 schrieb Jim Jagielski:
>>> On Dec 2, 2017, at 8:39 AM, Marcus >> > wrote:
>>>
>>> Am 02.12.2017 um 13:22 schrieb Matthias Seidel:
 Despite of the name it could be the icon of the dmg file? I don't
 know where this icon set is visible... ;-)
 Apart from that: +1 for a public beta.
 But we should build "real" beta builds, with the appropriate
 naming/graphics:
 https://home.apache.org/~mseidel/AOO-builds/AOO-420-Beta/About%20OpenOffice%20Beta%204.2.0.png

>>>
>>> oh yes, good hint. IMHO the splash screen and start center graphic
>>> should show clearly that this is a beta release. Plus different
>>> filenames for the installation files.
>>>
>>
>> Here are the results on macOS:
>
> that looks great. On the start center it's a bit different. "beta"
> should be aligned with the productname/version like for the splash screen.

These are the original graphics from 2014...

Technically seen there is no way to put the "beta" behind the product name:
https://svn.apache.org/repos/asf/openoffice/trunk/main/default_images/framework/res/beta/backing.png

But I am working on that for a while and I would like to propose a
"redesign" of the Start Center:
https://bz.apache.org/ooo/show_bug.cgi?id=127158#c15

Of course this would include a nicer version for beta builds.

Regards, Matthias

>
>
> Marcus
>
>
> -
> 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: [PROPOSAL] Public Beta for 4.2


Am 02.12.2017 um 23:21 schrieb Jim Jagielski:
On Dec 2, 2017, at 8:39 AM, Marcus > wrote:


Am 02.12.2017 um 13:22 schrieb Matthias Seidel:
Despite of the name it could be the icon of the dmg file? I don't 
know where this icon set is visible... ;-)

Apart from that: +1 for a public beta.
But we should build "real" beta builds, with the appropriate 
naming/graphics:

https://home.apache.org/~mseidel/AOO-builds/AOO-420-Beta/About%20OpenOffice%20Beta%204.2.0.png


oh yes, good hint. IMHO the splash screen and start center graphic 
should show clearly that this is a beta release. Plus different 
filenames for the installation files.




Here are the results on macOS:


that looks great. On the start center it's a bit different. "beta" 
should be aligned with the productname/version like for the splash screen.


Marcus


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

Re: a more sane way to override optimization flags in gbuild