Re: [RELEASE]: OpenOffice 4.0 RC availability

[Ariel Constenla-Haile]

On Fri, Jul 12, 2013 at 11:38 AM, Ariel Constenla-Haile
 wrote:
> 64 bit packages are ready. 32 bit packages are still being uploaded.

All packages are ready now.

Regards

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

Re: New Extensions website goes live!

[Roberto Galoppini]

2013/7/9 Roberto Galoppini 

>
>
>
> 2013/7/8 Rob Weir 
>
>> On Sat, Jul 6, 2013 at 4:18 PM, Roberto Galoppini
>>  wrote:
>> > We are updating http://extensions.openoffice.org to tturn on all
>> > enhancements previously made available at the test website.
>> >
>>
>> This is great news, Roberto!
>>
>
> Indeed!
>
>
>> Are you planning a blog post related to this at SourceForge?  Or
>> should we plan something for the AOO blog?  (Or both?)
>>
>
> I'll cover that at the SF blog as usual, open to do something that makes
> sense for AOO blog too, sure.
>
> Give me a day or two, I want to finalize the migration before.
>

AOOE has been successfully migrated, below a concise list of improvements,
a blog post on SF will follow next week (possibly coordinating  that with
the new AOO release).

1. The whole platform has been upgraded to a web 2.0ish style. Adding more
content, serve developers' needs as well as scale with end-users' growth is
easier now.

2. The look&feel has been updated and aligned with the new AOO 4 look. We
put the word 'beta' in the header, to be removed once the new release will
go out.

3.  The search has been improved and it provides the autocomplete
functionality (try it out writing 'dr' for example).

4. The auto-update for Extensions has been reactivated.

5. A new feature allows devs to report AOO 4.0 compatibility for their
extensions, and by default we set all to 'unknown'. Have a look at
http://extensions.openoffice.org/upgrade/400/abcdef+754758+df418f+a81383 to
get an example.

Note that to take full advantage of this new feature we need authors to set
properly the compatibility field, and to crack a new Extension to check
extensions compatibility or changes (it should check which extensions are
installed, e.g. A, B, C and then call
http://extensions.openoffice.org/upgrade/400/A+B+C). Maybe we can discuss
further option once AOO 4 will be released.

6. Finally Extensions authors have full control over comments and spam.

Roberto




>
> Roberto
>
>
>>
>> Do you have a list of changes that we can reference?
>>
>> Regards,
>>
>> -Rob
>>
>>
>> > All users accounts will be migrated, along with associated passwords and
>> > users content.
>> >
>> >  http://extensions.openoffice.org may be temporarily unavailable or
>> slow
>> > down.
>> >
>> > Once the migration will be completed "update notifications" will be
>> > activated.
>> >
>> > Roberto
>>
>
>

Re: [DISCUSS][VOTE]: Release OpenOffice 4.0 (RC)

[Ariel Constenla-Haile]

On Fri, Jul 12, 2013 at 11:54 PM, imacat  wrote:
> Sorry.  I did not see Traditional Chinese version.  Did I missed
> something on the Traditional Chinese version?

UI translation is not complete: https://translate.apache.org/zh_TW/aoo40/

Regards

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

Re: [DISCUSS][VOTE]: Release OpenOffice 4.0 (RC)

[imacat]

Sorry.  I did not see Traditional Chinese version.  Did I missed
something on the Traditional Chinese version?  Thank you.

On 2013/07/12 21:52, Jürgen Schmidt said:
> please don't discuss in a vote thread
> 
> 
> @Raphael, I disagree we do testing on snapshots since weeks.
> 
> Juergen
> 
> 
> On 7/12/13 3:43 PM, Rob Weir wrote:
>> On Fri, Jul 12, 2013 at 9:23 AM, Raphael Bircher  wrote:
>>> Hi at all
>>>
>>> Moment Jürgen. Test a RC and final vote. within 72 houers is unserios. Pleas
>>> give a a full week for this. Else i will vote -1 because there is not
>>> enought time to make the final tests.
>>>
>>
>> The previous dev snapshot (rev. 1499347)  build was July 5th.  That
>> was 8 days ago.  So there has been over a week for anyone who was
>> interested in doing more testing or reporting any new release
>> blockers.
>>
>> With the RC I think we can be more focused and verify the fixed bugs
>> and test around any areas that changed since the last dev snapshot.
>>
>> (Think of it this way:  If Juergen had labeled the July 5th dev
>> snapshot as "RC 1" and today's build as "RC 2", would any more testing
>> have occurred?  Would anything be different?)
>>
>> Regards,
>>
>> -Rob
>>
>>
>>> Greetings Raphael
>>>
>>> Am 12.07.13 11:11, schrieb Jürgen Schmidt:
>>>
 Hi all,

 this is a call for vote on releasing the following release candidate as
 Apache OpenOffice 4.0. This will be an important release for Apache
 OpenOffice with bigger visible UI changes. It is a key milestone to
 continue the success of OpenOffice.

 This release candidate provides the following important changes compared
 to former OpenOffice releases:

 (1) a major UI change/improvement by introducing a new sidebar concept
 where the idea is the comes from IBM's Symphony. It's the combination of
 reimplementing a complete new framework for sidebars and merging the
 existing sidebar in impress and code of various content panels from the
 Symphony grant in OpenOffice.

 (2) 190 fixes from Symphony are merged and integrated, mainly
 interoperability issues

 (3) 600 defects are fixed

 (4) many more features and improvements are integrated

 For a detailed feature overview please see the release notes under

 https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes.
 But keep in mind that the release notes are not yet final and will be
 updated and polished ...

 The release candidate artifacts (source release, as well as binary
 releases for 23 languages) and further information how to verify and
 review Apache OpenOffice 4.0 can be found on the following wiki page:


 https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshot

 The related RAT scan for this RC can be found under
 http://people.apache.org/~jsc/aoo-4.0.0_rat/aoo-4.0.0_rat-output.html

 The RC is based on the release branch AOO400, revision 1502185!

 Please vote on releasing this package as Apache OpenOffice 4.0.

 The vote starts now and will be open until:

 UTC at noon on Monday, 15 July: 2013-07-15 12:00 UTC.

 But we invite all people to vote (non binding) on this RC. We would like
 to provide a release that is supported by the majority of our project
 members.

 [ ] +1 Release this package as Apache OpenOffice 4.0
 [ ]  0 Don't care
 [ ] -1 Do not release this package because...

 -
 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
>>
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-- 
Best regards,
imacat ^_*' 
PGP Key http://www.imacat.idv.tw/me/pgpkey.asc

<> News: http://www.wov.idv.tw/
Tavern IMACAT's http://www.imacat.idv.tw/
Woman in FOSS in Taiwan http://wofoss.blogspot.com/
OpenOffice http://www.openoffice.org/
EducOO/OOo4Kids Taiwan http://www.educoo.tw/
Greenfoot Taiwan http://greenfoot.westart.tw/



signature.asc
Description: OpenPGP digital signature

Re: [VOTE]: Release OpenOffice 4.0 (RC)

[Ricardo Berlasso]

2013/7/12 Jürgen Schmidt 

> Hi all,
>
> this is a call for vote on releasing the following release candidate as
> Apache OpenOffice 4.0. This will be an important release for Apache
> OpenOffice with bigger visible UI changes. It is a key milestone to
> continue the success of OpenOffice.
>
> This release candidate provides the following important changes compared
> to former OpenOffice releases:
>
> (1) a major UI change/improvement by introducing a new sidebar concept
> where the idea is the comes from IBM's Symphony. It's the combination of
> reimplementing a complete new framework for sidebars and merging the
> existing sidebar in impress and code of various content panels from the
> Symphony grant in OpenOffice.
>
> (2) 190 fixes from Symphony are merged and integrated, mainly
> interoperability issues
>
> (3) 600 defects are fixed
>
> (4) many more features and improvements are integrated
>
> For a detailed feature overview please see the release notes under
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes
> .
> But keep in mind that the release notes are not yet final and will be
> updated and polished ...
>
> The release candidate artifacts (source release, as well as binary
> releases for 23 languages) and further information how to verify and
> review Apache OpenOffice 4.0 can be found on the following wiki page:
>
>
> https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshot
>
> The related RAT scan for this RC can be found under
> http://people.apache.org/~jsc/aoo-4.0.0_rat/aoo-4.0.0_rat-output.html
>
> The RC is based on the release branch AOO400, revision 1502185!
>
> Please vote on releasing this package as Apache OpenOffice 4.0.
>
> The vote starts now and will be open until:
>
>UTC at noon on Monday, 15 July: 2013-07-15 12:00 UTC.
>
> But we invite all people to vote (non binding) on this RC. We would like
> to provide a release that is supported by the majority of our project
> members.
>
>[ ] +1 Release this package as Apache OpenOffice 4.0
>[ ]  0 Don't care
>[ ] -1 Do not release this package because...
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

+1 Release this package as Apache OpenOffice 4.0

I'm using the dev builds on a daily basis since some time now, and this
last build solved the few problems I had.

Regards
Ricardo

Re: [DISCUSS][VOTE]: Release OpenOffice 4.0 (RC)

[Dave Fisher]

On Jul 12, 2013, at 9:11 AM, Ariel Constenla-Haile wrote:

> On Fri, Jul 12, 2013 at 12:48 PM, Rob Weir  wrote:
>> Does anyone have a script to verify signatures and hashes for a release?
>> 
>> In previous releases I'd download everything and do some ad-hoc
>> commands, but not as automated as it could be.  Since we have a
>> regular directory structure it should be possible to have a script
>> that would verify everything and produce a report.
> 
> unless you are trying to verify the download, there is no need to
> download anything, just ssh to people.apache.org and check the
> integrity in place once moved to the  /www/www.apache.org/dist/
> folder.
> Something like:
> 
> arielch@~$ for i in
> /home/jsc/public_html/developer-snapshots/RC/4.0.0/binaries/*/*.asc ;
> do echo "Checking $i" && gpg2 --verify $i;done

To properly vote on a release requires some verification steps. Rob's idea is 
one I have been thinking about as well.

To the point of a 72 hour VOTE. I think that ONE WEEK would be good for the 
project if only because it would allow people to adjust their schedules.

Personally I prefer the weekend, but a VOTE on Apache OpenOffice took me about 
4-8 hours of work for 3.4 and 3.4.1 - and my time is committed this weekend.

So, if I have time I'll vote. Otherwise, thanks and I trust the PMC to do what 
is best for the project.

Regards,
Dave




> 
> 
> Regards
> 
> -
> 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: [DISCUSS][VOTE]: Release OpenOffice 4.0 (RC)

[Kay Schenk]

On Fri, Jul 12, 2013 at 8:48 AM, Rob Weir  wrote:

> Does anyone have a script to verify signatures and hashes for a release?
>
> In previous releases I'd download everything and do some ad-hoc
> commands, but not as automated as it could be.  Since we have a
> regular directory structure it should be possible to have a script
> that would verify everything and produce a report.
>
> Does anyone have something like this?
>
> -Rob
>

I'm assuming you mean something that would do the series of commands
explained in this page:

 http://www.openoffice.org/download/checksums/3.4.1_checksums.html#howto

but for all our versions?

I don't have such a script--Perl! But, definitely something to think about
soonish...


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


-- 
-
MzK

"Every day we should hear at least one little song,
 read one good poem, see one exquisite picture,
 and, if possible, speak a few sensible words."
 -- Johann Wolfgang von Goethe

Re: Where to keep release notes?

[Kay Schenk]

On Fri, Jul 12, 2013 at 4:45 PM, Rob Weir  wrote:

> On Fri, Jul 12, 2013 at 3:52 PM, Kay Schenk  wrote:
> > On Fri, Jul 12, 2013 at 12:17 PM, Rob Weir  wrote:
> >
> >> On Jul 12, 2013, at 2:26 PM, "Marcus (OOo)" 
> wrote:
> >>
> >> > Am 07/12/2013 07:18 PM, schrieb janI:
> >> >> On 12 July 2013 18:49, Rob Weir  wrote:
> >> >>
> >> >>> In the past we drafted release notes on the wiki, and then moved
> them
> >> >>> to a location on the website.  I'd like to challenge our thinking on
> >> >>> this.
> >> >>>
> >> >>> Wouldn't it be useful to keep the release notes as a "live" document
> >> >>> on the wiki, so we can easily update it with additional information
> on
> >> >>> known issues as they are found, especially after release?
> >> >>
> >> >> I see your point, however I disagree.
> >> >>
> >> >> I think the release doc. for 4.0 is part of the release and should be
> >> >> frozen in svn like all other release artifacts. This is done by
> having
> >> it
> >> >> as a static web page.
> >> >
> >> > I support the doubts of Jan.
> >> >
> >> > The release notes should be seen as an artifact from a release as they
> >> describe this. We can also go that far that we write down the SVN
> revision
> >> number into the release notes. Then they are really tied strictly to
> this
> >> release and nothing else.
> >> >
> >>
> >> And I did not mean to suggest anything else. The wiki page would be
> >> tied to a specific version of AOO, a different page for each version.
> >> But it would be  updated to reflect the latest info, especially in the
> >> "known problems" section.
> >>
> >>
> >>
> >> >> We can then have a "latest information", which are live in wiki.
> >> >
> >> > What about to put a link like this at the top of the release notes to
> >> give it more visible attention:
> >> >
> >> > Text: "For the latest information about Apache OpenOffice 4.0 see
> >> >  this related Wiki page."
> >> > Link: http://wiki.openoffice.org/wiki/AOO400_Lastest_Info
> >> >
> >>
> >> Look at it from the perspective of the user. They want one place to go
> >> for relevant info related to the release and problems they might
> >> encounter. They don't want to hunt around for "old" versus "new" info.
> >> Those distinctions are not relevant to a new user.
> >>
> >> For example, imagine Windows 8.1 comes out and causes a problem with
> >> AOO4, but there is a good workaround that could save the user much
> >> frustration.  But the release notes don't mention this. They just say
> >> Windows 8 is tested. This is not very helpful.
> >>
> >>
> >> > Then new and important / noteable changes can be documented in the
> (more
> >> easily accessible) Wiki.
> >> >
> >>
> >> My proposal was to handle this by keeping the release notes on a wiki
> >> page so such changes are seen by users with the least effort for them
> >> and us.
> >>
> >> -Rob
> >>
> >
> > Arguments either way it seems.  Leaving them on the wiki would certainly
> be
> > good especially for last minute changes -- which have happened.  I guess
> it
> > boils down to -- when a release is announced, where are the Release Notes
> > of record? and if things change -- i.e. *New* Discovered Issues, as
> opposed
> > to Known Issues in the Release Notes -- should this be kept as a separate
> > entity that is not part of the Release Notes of record? OK, a lot of
> legal
> > gobbly gook I guess
> >
>
> Two separate considerations, perhaps:
>
> 1) Whether Release Notes are updated overtime, post-release, based on
> feedback from users and discovery of new issues?  Or are they
> frozen-in-time, snapshots that never change, but might point to a
> different page that is updated.
>
> 2) What technology we use to create, publish and (if needed) update
> the release notes.
>
> It is possible to have a "living" document for Release Notes and do it
> entirely in HTML on the website.  It is possible to do it on the wiki.
>  It is even possible to do it on the committer-only CWiki.   (Anyone
> remember that we have that?)
>

NO -- I do not remember or even know anything about this.  I think if we
utilized that approach, maybe this is an equitable solution.


> Since we all seem to like drafting the release notes on the wiki, it
> might reduce the work if we just keep it there.  It makes it easier
> for translators as well.  But I'm not too concerned with the except
> technology used.  I'm more concerned with keeping it up to date, and
> easy to understand.


I understand.


>  In other words, if we have a section called
> "known issues", I want it to remain accurate as new issues are
> discovered.  It is 2013 and this is the internet.  We shouldn't have a
> "let's slip an errata sheet into a hardbound book" mentality about
> this.
>

Your points are good for this. Really my major concern with the wiki was
maybe the ease of unwarranted edits. Other than that, I'm fine with
this...dealing with proting it to web server is not that hard but a step we
might all be happy to avoid.

now to look into the Co

Re: Where to keep release notes?

[Rob Weir]

On Fri, Jul 12, 2013 at 3:52 PM, Kay Schenk  wrote:
> On Fri, Jul 12, 2013 at 12:17 PM, Rob Weir  wrote:
>
>> On Jul 12, 2013, at 2:26 PM, "Marcus (OOo)"  wrote:
>>
>> > Am 07/12/2013 07:18 PM, schrieb janI:
>> >> On 12 July 2013 18:49, Rob Weir  wrote:
>> >>
>> >>> In the past we drafted release notes on the wiki, and then moved them
>> >>> to a location on the website.  I'd like to challenge our thinking on
>> >>> this.
>> >>>
>> >>> Wouldn't it be useful to keep the release notes as a "live" document
>> >>> on the wiki, so we can easily update it with additional information on
>> >>> known issues as they are found, especially after release?
>> >>
>> >> I see your point, however I disagree.
>> >>
>> >> I think the release doc. for 4.0 is part of the release and should be
>> >> frozen in svn like all other release artifacts. This is done by having
>> it
>> >> as a static web page.
>> >
>> > I support the doubts of Jan.
>> >
>> > The release notes should be seen as an artifact from a release as they
>> describe this. We can also go that far that we write down the SVN revision
>> number into the release notes. Then they are really tied strictly to this
>> release and nothing else.
>> >
>>
>> And I did not mean to suggest anything else. The wiki page would be
>> tied to a specific version of AOO, a different page for each version.
>> But it would be  updated to reflect the latest info, especially in the
>> "known problems" section.
>>
>>
>>
>> >> We can then have a "latest information", which are live in wiki.
>> >
>> > What about to put a link like this at the top of the release notes to
>> give it more visible attention:
>> >
>> > Text: "For the latest information about Apache OpenOffice 4.0 see
>> >  this related Wiki page."
>> > Link: http://wiki.openoffice.org/wiki/AOO400_Lastest_Info
>> >
>>
>> Look at it from the perspective of the user. They want one place to go
>> for relevant info related to the release and problems they might
>> encounter. They don't want to hunt around for "old" versus "new" info.
>> Those distinctions are not relevant to a new user.
>>
>> For example, imagine Windows 8.1 comes out and causes a problem with
>> AOO4, but there is a good workaround that could save the user much
>> frustration.  But the release notes don't mention this. They just say
>> Windows 8 is tested. This is not very helpful.
>>
>>
>> > Then new and important / noteable changes can be documented in the (more
>> easily accessible) Wiki.
>> >
>>
>> My proposal was to handle this by keeping the release notes on a wiki
>> page so such changes are seen by users with the least effort for them
>> and us.
>>
>> -Rob
>>
>
> Arguments either way it seems.  Leaving them on the wiki would certainly be
> good especially for last minute changes -- which have happened.  I guess it
> boils down to -- when a release is announced, where are the Release Notes
> of record? and if things change -- i.e. *New* Discovered Issues, as opposed
> to Known Issues in the Release Notes -- should this be kept as a separate
> entity that is not part of the Release Notes of record? OK, a lot of legal
> gobbly gook I guess
>

Two separate considerations, perhaps:

1) Whether Release Notes are updated overtime, post-release, based on
feedback from users and discovery of new issues?  Or are they
frozen-in-time, snapshots that never change, but might point to a
different page that is updated.

2) What technology we use to create, publish and (if needed) update
the release notes.

It is possible to have a "living" document for Release Notes and do it
entirely in HTML on the website.  It is possible to do it on the wiki.
 It is even possible to do it on the committer-only CWiki.   (Anyone
remember that we have that?)

Since we all seem to like drafting the release notes on the wiki, it
might reduce the work if we just keep it there.  It makes it easier
for translators as well.  But I'm not too concerned with the except
technology used.  I'm more concerned with keeping it up to date, and
easy to understand.  In other words, if we have a section called
"known issues", I want it to remain accurate as new issues are
discovered.  It is 2013 and this is the internet.  We shouldn't have a
"let's slip an errata sheet into a hardbound book" mentality about
this.

> I personally find it annoying to get "instructions" and "issues" at a site
> one day, that somehow morph into something else the next. Even if these
> things are not legally binding, there's that sort of confusion factor.
>

I think most users consult the page rarely.  They might look once when
they install initially.  And then they look again perhaps, if they run
into a problem.  One advantage of the release notes in particular (and
this is true of no other page) is that they tend to have higher Google
PageRank, because they are linked to from news articles.  So users who
query for things like "apache openoffice 4.0 issues" will tend to find
that page high on their results list.  This would 

Re: Where to keep release notes?

[Rob Weir]

On Fri, Jul 12, 2013 at 5:39 PM, janI  wrote:
> On 12 July 2013 22:44, Marcus (OOo)  wrote:
>
>> Am 07/12/2013 09:17 PM, schrieb Rob Weir:
>>
>>  On Jul 12, 2013, at 2:26 PM, "Marcus (OOo)"  wrote:
>>>
>>>  Am 07/12/2013 07:18 PM, schrieb janI:

> On 12 July 2013 18:49, Rob Weir   wrote:
>
>  In the past we drafted release notes on the wiki, and then moved them
>> to a location on the website.  I'd like to challenge our thinking on
>> this.
>>
>> Wouldn't it be useful to keep the release notes as a "live" document
>> on the wiki, so we can easily update it with additional information on
>> known issues as they are found, especially after release?
>>
>
> I see your point, however I disagree.
>
> I think the release doc. for 4.0 is part of the release and should be
> frozen in svn like all other release artifacts. This is done by having
> it
> as a static web page.
>

 I support the doubts of Jan.

 The release notes should be seen as an artifact from a release as they
 describe this. We can also go that far that we write down the SVN revision
 number into the release notes. Then they are really tied strictly to this
 release and nothing else.


>>> And I did not mean to suggest anything else. The wiki page would be
>>> tied to a specific version of AOO, a different page for each version.
>>> But it would be  updated to reflect the latest info, especially in the
>>> "known problems" section.
>>>
>>
>> You suggested to put the release notes *and* latest information into the
>> Wiki, not only the last.
>>
>>
>>  We can then have a "latest information", which are live in wiki.
>

 What about to put a link like this at the top of the release notes to
 give it more visible attention:

 Text: "For the latest information about Apache OpenOffice 4.0 see
   this related Wiki page."
 Link: 
 http://wiki.openoffice.org/**wiki/AOO400_Lastest_Info


>>> Look at it from the perspective of the user. They want one place to go
>>> for relevant info related to the release and problems they might
>>> encounter. They don't want to hunt around for "old" versus "new" info.
>>> Those distinctions are not relevant to a new user.
>>>
>>
>> Look from the perspective of a forum user. They ask "Why does function X
>> not work on OS Y?" and they could be pointed to the Wiki page with the
>> "Known Issues" part, without the need to read all the oher stuff.
>>
>>
>>  For example, imagine Windows 8.1 comes out and causes a problem with
>>> AOO4, but there is a good workaround that could save the user much
>>> frustration.  But the release notes don't mention this. They just say
>>> Windows 8 is tested. This is not very helpful.
>>>
>>
>> Great, just point them to the Wiki page.
>>
>>
>>  Then new and important / noteable changes can be documented in the (more
 easily accessible) Wiki.

>>>
>>> My proposal was to handle this by keeping the release notes on a wiki
>>> page so such changes are seen by users with the least effort for them
>>> and us.
>>>
>>
>> I still would like to see the (real) release notes in SVN control and
>> finally on a webpage. And the things that occur suddenly until the next
>> release can go into the Wiki.
>>
>> We are not that far away from each others opinion. ;-)
>
>
> I think you have an extra point, compared to my first post. Keeping (real)
> release notes fixed (web page / svn) and have "last notes" in wiki, will
> make the latter slim and fast to read, so we can hope the users actually
> read it.
>

Imagine you take some medicine, and the jar has some instructions and
warnings on it.  And then there is some fine print that says, "for
updated warnings, go to this web page".  Do you think that would work
well?  Perhaps, with physical things we are limited in that way.  But
if the information is natively digital, why wouldn't you update it in
place, so the reader gets all of the information at once?  Why would
any user care about "original" versus "updated" information?  Why is
that even a distinction that they care about?  Don't they really just
want to know *only* the relevant current information?

As for keeping it slim, I agree there.  But that does not mean that we
segregate relevant updated information.  It means that we structure
the release notes carefully so all information is easy to find, and we
make it clear what information is critical.   We fail to do that if we
put important information on a secondary page just because it was
found later.

Remember, your approach has already been shown to fail in the case of
the profile corruption issue we had with AOO 3.4.0. Why not try
sometime else this time?

-Rob


> rgds
> jan I.
>
>
>>
>>
>> Marcus
>>
>>
>>
>>  Remember, even if the issue is not caused by AOO code, a new upgrade
>> to a dependent operating system or other 3rd party app

Re: Where to keep release notes?

[Rob Weir]

On Fri, Jul 12, 2013 at 4:44 PM, Marcus (OOo)  wrote:
> Am 07/12/2013 09:17 PM, schrieb Rob Weir:
>
>> On Jul 12, 2013, at 2:26 PM, "Marcus (OOo)"  wrote:
>>
>>> Am 07/12/2013 07:18 PM, schrieb janI:

 On 12 July 2013 18:49, Rob Weir   wrote:

> In the past we drafted release notes on the wiki, and then moved them
> to a location on the website.  I'd like to challenge our thinking on
> this.
>
> Wouldn't it be useful to keep the release notes as a "live" document
> on the wiki, so we can easily update it with additional information on
> known issues as they are found, especially after release?


 I see your point, however I disagree.

 I think the release doc. for 4.0 is part of the release and should be
 frozen in svn like all other release artifacts. This is done by having
 it
 as a static web page.
>>>
>>>
>>> I support the doubts of Jan.
>>>
>>> The release notes should be seen as an artifact from a release as they
>>> describe this. We can also go that far that we write down the SVN revision
>>> number into the release notes. Then they are really tied strictly to this
>>> release and nothing else.
>>>
>>
>> And I did not mean to suggest anything else. The wiki page would be
>> tied to a specific version of AOO, a different page for each version.
>> But it would be  updated to reflect the latest info, especially in the
>> "known problems" section.
>
>
> You suggested to put the release notes *and* latest information into the
> Wiki, not only the last.
>

Specifically, I'm proposing that these are the same thing.  Remember,
we already have a section in the release notes called "known issues".
It sounds like you want that to be a snapshot of what was known at a
fixed point in time, and then force the user to go to a different page
to find timely information.  Why make them do that?


>
 We can then have a "latest information", which are live in wiki.
>>>
>>>
>>> What about to put a link like this at the top of the release notes to
>>> give it more visible attention:
>>>
>>> Text: "For the latest information about Apache OpenOffice 4.0 see
>>>   this related Wiki page."
>>> Link: http://wiki.openoffice.org/wiki/AOO400_Lastest_Info
>>>
>>
>> Look at it from the perspective of the user. They want one place to go
>> for relevant info related to the release and problems they might
>> encounter. They don't want to hunt around for "old" versus "new" info.
>> Those distinctions are not relevant to a new user.
>
>
> Look from the perspective of a forum user. They ask "Why does function X not
> work on OS Y?" and they could be pointed to the Wiki page with the "Known
> Issues" part, without the need to read all the oher stuff.
>

If the user was not able to find a solution themselves then we have
already failed.  The forums are not a solution for 50 million users.
We still need to make an effort to provide relevant information to the
user *at the time they download AOO*.

A specific example.  AOO 3.4.0 had a problem with migration extensions
which caused a crash that lead to a huge number of reports to the
forums and the mailing list and bugzilla.  We're still cleaning up the
mess.  We get many reports on this on Facebook as well.   Doesn't it
make sense for the user to know about this information, and the easy
workaround, when they download AOO initially?  Why make them hunt for
the info?  Is it really relevant, from a user support perspective,
whether the issue and workaround was known on the day we released
versus an issue found a month later?  Do you really think the user
expects the former to be found in one place and the latter in another
place?  Really?

>
>> For example, imagine Windows 8.1 comes out and causes a problem with
>> AOO4, but there is a good workaround that could save the user much
>> frustration.  But the release notes don't mention this. They just say
>> Windows 8 is tested. This is not very helpful.
>
>
> Great, just point them to the Wiki page.
>

Again, I'm trying to encourage self-service remedies for millions of
users.  Once they come here to ask a question they are already
frustrated and we have already failed them.

>
>>> Then new and important / noteable changes can be documented in the (more
>>> easily accessible) Wiki.
>>
>>
>> My proposal was to handle this by keeping the release notes on a wiki
>> page so such changes are seen by users with the least effort for them
>> and us.
>
>
> I still would like to see the (real) release notes in SVN control and
> finally on a webpage. And the things that occur suddenly until the next
> release can go into the Wiki.
>
> We are not that far away from each others opinion. ;-)
>

Perhaps, but I would like you to consider again this from the user's
perspective and what would make it easiest for them to resolve issues
without flooding our mailing lists for questions that we already know
about.

Regards,

-Rob


>
> Marcus
>
>
>
> Remember, even if the issue is no

Re: Where to keep release notes?

[janI]

On 12 July 2013 22:44, Marcus (OOo)  wrote:

> Am 07/12/2013 09:17 PM, schrieb Rob Weir:
>
>  On Jul 12, 2013, at 2:26 PM, "Marcus (OOo)"  wrote:
>>
>>  Am 07/12/2013 07:18 PM, schrieb janI:
>>>
 On 12 July 2013 18:49, Rob Weir   wrote:

  In the past we drafted release notes on the wiki, and then moved them
> to a location on the website.  I'd like to challenge our thinking on
> this.
>
> Wouldn't it be useful to keep the release notes as a "live" document
> on the wiki, so we can easily update it with additional information on
> known issues as they are found, especially after release?
>

 I see your point, however I disagree.

 I think the release doc. for 4.0 is part of the release and should be
 frozen in svn like all other release artifacts. This is done by having
 it
 as a static web page.

>>>
>>> I support the doubts of Jan.
>>>
>>> The release notes should be seen as an artifact from a release as they
>>> describe this. We can also go that far that we write down the SVN revision
>>> number into the release notes. Then they are really tied strictly to this
>>> release and nothing else.
>>>
>>>
>> And I did not mean to suggest anything else. The wiki page would be
>> tied to a specific version of AOO, a different page for each version.
>> But it would be  updated to reflect the latest info, especially in the
>> "known problems" section.
>>
>
> You suggested to put the release notes *and* latest information into the
> Wiki, not only the last.
>
>
>  We can then have a "latest information", which are live in wiki.

>>>
>>> What about to put a link like this at the top of the release notes to
>>> give it more visible attention:
>>>
>>> Text: "For the latest information about Apache OpenOffice 4.0 see
>>>   this related Wiki page."
>>> Link: 
>>> http://wiki.openoffice.org/**wiki/AOO400_Lastest_Info
>>>
>>>
>> Look at it from the perspective of the user. They want one place to go
>> for relevant info related to the release and problems they might
>> encounter. They don't want to hunt around for "old" versus "new" info.
>> Those distinctions are not relevant to a new user.
>>
>
> Look from the perspective of a forum user. They ask "Why does function X
> not work on OS Y?" and they could be pointed to the Wiki page with the
> "Known Issues" part, without the need to read all the oher stuff.
>
>
>  For example, imagine Windows 8.1 comes out and causes a problem with
>> AOO4, but there is a good workaround that could save the user much
>> frustration.  But the release notes don't mention this. They just say
>> Windows 8 is tested. This is not very helpful.
>>
>
> Great, just point them to the Wiki page.
>
>
>  Then new and important / noteable changes can be documented in the (more
>>> easily accessible) Wiki.
>>>
>>
>> My proposal was to handle this by keeping the release notes on a wiki
>> page so such changes are seen by users with the least effort for them
>> and us.
>>
>
> I still would like to see the (real) release notes in SVN control and
> finally on a webpage. And the things that occur suddenly until the next
> release can go into the Wiki.
>
> We are not that far away from each others opinion. ;-)


I think you have an extra point, compared to my first post. Keeping (real)
release notes fixed (web page / svn) and have "last notes" in wiki, will
make the latter slim and fast to read, so we can hope the users actually
read it.

rgds
jan I.


>
>
> Marcus
>
>
>
>  Remember, even if the issue is not caused by AOO code, a new upgrade
> to a dependent operating system or other 3rd party application can
> cause new issues to appear at any time.  So keeping  the release notes
> updated is important.
>

 This issue is highly caused by AOO code, remember the release code is
 tested with a given set of third party libraries and given versions of
 the
 operating systems.

 Release notes reflect the environment tested for the 4.0 release,
 everything that comes later should either be kept in a separate
 document or
 postponed to a new release.



> Do we lose anything if we do this?  For example, is there a concern
> that the wiki can not handle the load?
>

 Wiki can handle the load (it must because a lot of people will search
 for
 info).

 Yes we loose trackability. Release notes is in svn (in my opinion).
 Remember in wiki anybody can change, so if person X test AOO on
 platform Y
 should he/she  then just update the release documentation, I hope not.

 But again, your idea of a live document is good, I just see it as a
 second
 document (similar to what a lot of companies does).

>>>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additio

autocorrect macro?

[The weird writer]

I know this is a developer’s email list, but I'm a user and since this 
list is filled with developers I’d like to suggest a macro. I want to be 
able to import autocorrect entries from Microsoft word to open office. 
I’d gladly donate to this project or even purchase this functionality 
for a small fee, but as I have cerebral palsy I use AutoCorrect as an 
accessibility tool and I don’t want to manually import a bunch of 
entries, I’d say 1 thousand. Is this being developed, will it EVER be in 
a release of open office or do I have to look towards libre office?



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

Re: Where to keep release notes?

[Marcus (OOo)]

Am 07/12/2013 09:17 PM, schrieb Rob Weir:

On Jul 12, 2013, at 2:26 PM, "Marcus (OOo)"  wrote:


Am 07/12/2013 07:18 PM, schrieb janI:

On 12 July 2013 18:49, Rob Weir   wrote:


In the past we drafted release notes on the wiki, and then moved them
to a location on the website.  I'd like to challenge our thinking on
this.

Wouldn't it be useful to keep the release notes as a "live" document
on the wiki, so we can easily update it with additional information on
known issues as they are found, especially after release?


I see your point, however I disagree.

I think the release doc. for 4.0 is part of the release and should be
frozen in svn like all other release artifacts. This is done by having it
as a static web page.


I support the doubts of Jan.

The release notes should be seen as an artifact from a release as they describe 
this. We can also go that far that we write down the SVN revision number into 
the release notes. Then they are really tied strictly to this release and 
nothing else.



And I did not mean to suggest anything else. The wiki page would be
tied to a specific version of AOO, a different page for each version.
But it would be  updated to reflect the latest info, especially in the
"known problems" section.


You suggested to put the release notes *and* latest information into the 
Wiki, not only the last.



We can then have a "latest information", which are live in wiki.


What about to put a link like this at the top of the release notes to give it 
more visible attention:

Text: "For the latest information about Apache OpenOffice 4.0 see
  this related Wiki page."
Link: http://wiki.openoffice.org/wiki/AOO400_Lastest_Info



Look at it from the perspective of the user. They want one place to go
for relevant info related to the release and problems they might
encounter. They don't want to hunt around for "old" versus "new" info.
Those distinctions are not relevant to a new user.


Look from the perspective of a forum user. They ask "Why does function X 
not work on OS Y?" and they could be pointed to the Wiki page with the 
"Known Issues" part, without the need to read all the oher stuff.



For example, imagine Windows 8.1 comes out and causes a problem with
AOO4, but there is a good workaround that could save the user much
frustration.  But the release notes don't mention this. They just say
Windows 8 is tested. This is not very helpful.


Great, just point them to the Wiki page.


Then new and important / noteable changes can be documented in the (more easily 
accessible) Wiki.


My proposal was to handle this by keeping the release notes on a wiki
page so such changes are seen by users with the least effort for them
and us.


I still would like to see the (real) release notes in SVN control and 
finally on a webpage. And the things that occur suddenly until the next 
release can go into the Wiki.


We are not that far away from each others opinion. ;-)

Marcus




Remember, even if the issue is not caused by AOO code, a new upgrade
to a dependent operating system or other 3rd party application can
cause new issues to appear at any time.  So keeping  the release notes
updated is important.


This issue is highly caused by AOO code, remember the release code is
tested with a given set of third party libraries and given versions of the
operating systems.

Release notes reflect the environment tested for the 4.0 release,
everything that comes later should either be kept in a separate document or
postponed to a new release.




Do we lose anything if we do this?  For example, is there a concern
that the wiki can not handle the load?


Wiki can handle the load (it must because a lot of people will search for
info).

Yes we loose trackability. Release notes is in svn (in my opinion).
Remember in wiki anybody can change, so if person X test AOO on platform Y
should he/she  then just update the release documentation, I hope not.

But again, your idea of a live document is good, I just see it as a second
document (similar to what a lot of companies does).


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

Re: Where to keep release notes?

[Kay Schenk]

On Fri, Jul 12, 2013 at 12:17 PM, Rob Weir  wrote:

> On Jul 12, 2013, at 2:26 PM, "Marcus (OOo)"  wrote:
>
> > Am 07/12/2013 07:18 PM, schrieb janI:
> >> On 12 July 2013 18:49, Rob Weir  wrote:
> >>
> >>> In the past we drafted release notes on the wiki, and then moved them
> >>> to a location on the website.  I'd like to challenge our thinking on
> >>> this.
> >>>
> >>> Wouldn't it be useful to keep the release notes as a "live" document
> >>> on the wiki, so we can easily update it with additional information on
> >>> known issues as they are found, especially after release?
> >>
> >> I see your point, however I disagree.
> >>
> >> I think the release doc. for 4.0 is part of the release and should be
> >> frozen in svn like all other release artifacts. This is done by having
> it
> >> as a static web page.
> >
> > I support the doubts of Jan.
> >
> > The release notes should be seen as an artifact from a release as they
> describe this. We can also go that far that we write down the SVN revision
> number into the release notes. Then they are really tied strictly to this
> release and nothing else.
> >
>
> And I did not mean to suggest anything else. The wiki page would be
> tied to a specific version of AOO, a different page for each version.
> But it would be  updated to reflect the latest info, especially in the
> "known problems" section.
>
>
>
> >> We can then have a "latest information", which are live in wiki.
> >
> > What about to put a link like this at the top of the release notes to
> give it more visible attention:
> >
> > Text: "For the latest information about Apache OpenOffice 4.0 see
> >  this related Wiki page."
> > Link: http://wiki.openoffice.org/wiki/AOO400_Lastest_Info
> >
>
> Look at it from the perspective of the user. They want one place to go
> for relevant info related to the release and problems they might
> encounter. They don't want to hunt around for "old" versus "new" info.
> Those distinctions are not relevant to a new user.
>
> For example, imagine Windows 8.1 comes out and causes a problem with
> AOO4, but there is a good workaround that could save the user much
> frustration.  But the release notes don't mention this. They just say
> Windows 8 is tested. This is not very helpful.
>
>
> > Then new and important / noteable changes can be documented in the (more
> easily accessible) Wiki.
> >
>
> My proposal was to handle this by keeping the release notes on a wiki
> page so such changes are seen by users with the least effort for them
> and us.
>
> -Rob
>

Arguments either way it seems.  Leaving them on the wiki would certainly be
good especially for last minute changes -- which have happened.  I guess it
boils down to -- when a release is announced, where are the Release Notes
of record? and if things change -- i.e. *New* Discovered Issues, as opposed
to Known Issues in the Release Notes -- should this be kept as a separate
entity that is not part of the Release Notes of record? OK, a lot of legal
gobbly gook I guess

I personally find it annoying to get "instructions" and "issues" at a site
one day, that somehow morph into something else the next. Even if these
things are not legally binding, there's that sort of confusion factor.

I, too, really don't like the idea of anyone with a wiki account being able
to change these, especially with the possibility of  no general
consultation or consensus.



> > My 2 ct.
> >
> > Marcus
> >
> >
> >
> >>> Remember, even if the issue is not caused by AOO code, a new upgrade
> >>> to a dependent operating system or other 3rd party application can
> >>> cause new issues to appear at any time.  So keeping  the release notes
> >>> updated is important.
> >>
> >> This issue is highly caused by AOO code, remember the release code is
> >> tested with a given set of third party libraries and given versions of
> the
> >> operating systems.
> >>
> >> Release notes reflect the environment tested for the 4.0 release,
> >> everything that comes later should either be kept in a separate
> document or
> >> postponed to a new release.
> >>
> >>
> >>>
> >>> Do we lose anything if we do this?  For example, is there a concern
> >>> that the wiki can not handle the load?
> >>
> >> Wiki can handle the load (it must because a lot of people will search
> for
> >> info).
> >>
> >> Yes we loose trackability. Release notes is in svn (in my opinion).
> >> Remember in wiki anybody can change, so if person X test AOO on
> platform Y
> >> should he/she  then just update the release documentation, I hope not.
> >>
> >> But again, your idea of a live document is good, I just see it as a
> second
> >> document (similar to what a lot of companies does).
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
>
> -
> To unsubscribe, e-mail

Re: 4.0 Release Dashboard

[Kay Schenk]

On Fri, Jul 12, 2013 at 11:27 AM, Marcus (OOo)  wrote:

> Am 07/12/2013 09:51 AM, schrieb Andrea Pescetti:
>
>  Jürgen Schmidt wrote:
>>
>>> I am still asking why we need the sub directories under binaries? We
>>> have the file unique already and the language code is part of the file
>>> name. The SDK name is also unique.
>>>
>>
> This was discussed more than one time and we finally agreed to have this
> structure.
>
> Of course we can thing about this for the next release. But I think it's
> too late for this one as it would need changes in the DL scripting, new
> uploads on Apache Dist, new distributions on the SF mirrors.
>
>
>  They are still handy in case a user wants to browse all available
>> versions for a given language. It's still convenient to do so at times,
>> so I would keep this.
>>
>
> I can understand your point. However, I don't see a difference between:
>
> - every file in a single directory
> - every language file in its own directory
>
> The user can see the same files in his language folder or in the single
> folder. OK, except that it's a bit easier to look in a specific folder than
> to grep for the respective language in the big folder.
>
> However, the users can see all available files in the big table on the
> "other.html" webpage. If something is missing there, then it's a bug.
>
> Marcus


For collecting statistical information based on language, it it probably
easier to keep the language sub-directories I would think., or else all
this would need to be parsed out of the file names.


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


-- 
-
MzK

"Every day we should hear at least one little song,
 read one good poem, see one exquisite picture,
 and, if possible, speak a few sensible words."
 -- Johann Wolfgang von Goethe

Re: Where to keep release notes?

[Rob Weir]

On Jul 12, 2013, at 2:26 PM, "Marcus (OOo)"  wrote:

> Am 07/12/2013 07:18 PM, schrieb janI:
>> On 12 July 2013 18:49, Rob Weir  wrote:
>>
>>> In the past we drafted release notes on the wiki, and then moved them
>>> to a location on the website.  I'd like to challenge our thinking on
>>> this.
>>>
>>> Wouldn't it be useful to keep the release notes as a "live" document
>>> on the wiki, so we can easily update it with additional information on
>>> known issues as they are found, especially after release?
>>
>> I see your point, however I disagree.
>>
>> I think the release doc. for 4.0 is part of the release and should be
>> frozen in svn like all other release artifacts. This is done by having it
>> as a static web page.
>
> I support the doubts of Jan.
>
> The release notes should be seen as an artifact from a release as they 
> describe this. We can also go that far that we write down the SVN revision 
> number into the release notes. Then they are really tied strictly to this 
> release and nothing else.
>

And I did not mean to suggest anything else. The wiki page would be
tied to a specific version of AOO, a different page for each version.
But it would be  updated to reflect the latest info, especially in the
"known problems" section.



>> We can then have a "latest information", which are live in wiki.
>
> What about to put a link like this at the top of the release notes to give it 
> more visible attention:
>
> Text: "For the latest information about Apache OpenOffice 4.0 see
>  this related Wiki page."
> Link: http://wiki.openoffice.org/wiki/AOO400_Lastest_Info
>

Look at it from the perspective of the user. They want one place to go
for relevant info related to the release and problems they might
encounter. They don't want to hunt around for "old" versus "new" info.
Those distinctions are not relevant to a new user.

For example, imagine Windows 8.1 comes out and causes a problem with
AOO4, but there is a good workaround that could save the user much
frustration.  But the release notes don't mention this. They just say
Windows 8 is tested. This is not very helpful.


> Then new and important / noteable changes can be documented in the (more 
> easily accessible) Wiki.
>

My proposal was to handle this by keeping the release notes on a wiki
page so such changes are seen by users with the least effort for them
and us.

-Rob

> My 2 ct.
>
> Marcus
>
>
>
>>> Remember, even if the issue is not caused by AOO code, a new upgrade
>>> to a dependent operating system or other 3rd party application can
>>> cause new issues to appear at any time.  So keeping  the release notes
>>> updated is important.
>>
>> This issue is highly caused by AOO code, remember the release code is
>> tested with a given set of third party libraries and given versions of the
>> operating systems.
>>
>> Release notes reflect the environment tested for the 4.0 release,
>> everything that comes later should either be kept in a separate document or
>> postponed to a new release.
>>
>>
>>>
>>> Do we lose anything if we do this?  For example, is there a concern
>>> that the wiki can not handle the load?
>>
>> Wiki can handle the load (it must because a lot of people will search for
>> info).
>>
>> Yes we loose trackability. Release notes is in svn (in my opinion).
>> Remember in wiki anybody can change, so if person X test AOO on platform Y
>> should he/she  then just update the release documentation, I hope not.
>>
>> But again, your idea of a live document is good, I just see it as a second
>> document (similar to what a lot of companies does).
>
> -
> 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: 4.0 Release Dashboard

[Marcus (OOo)]

Am 07/12/2013 09:51 AM, schrieb Andrea Pescetti:

Jürgen Schmidt wrote:

I am still asking why we need the sub directories under binaries? We
have the file unique already and the language code is part of the file
name. The SDK name is also unique.


This was discussed more than one time and we finally agreed to have this 
structure.


Of course we can thing about this for the next release. But I think it's 
too late for this one as it would need changes in the DL scripting, new 
uploads on Apache Dist, new distributions on the SF mirrors.



They are still handy in case a user wants to browse all available
versions for a given language. It's still convenient to do so at times,
so I would keep this.


I can understand your point. However, I don't see a difference between:

- every file in a single directory
- every language file in its own directory

The user can see the same files in his language folder or in the single 
folder. OK, except that it's a bit easier to look in a specific folder 
than to grep for the respective language in the big folder.


However, the users can see all available files in the big table on the 
"other.html" webpage. If something is missing there, then it's a bug.


Marcus


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

Re: Where to keep release notes?

[Marcus (OOo)]

Am 07/12/2013 07:18 PM, schrieb janI:

On 12 July 2013 18:49, Rob Weir  wrote:


In the past we drafted release notes on the wiki, and then moved them
to a location on the website.  I'd like to challenge our thinking on
this.

Wouldn't it be useful to keep the release notes as a "live" document
on the wiki, so we can easily update it with additional information on
known issues as they are found, especially after release?



I see your point, however I disagree.

I think the release doc. for 4.0 is part of the release and should be
frozen in svn like all other release artifacts. This is done by having it
as a static web page.


I support the doubts of Jan.

The release notes should be seen as an artifact from a release as they 
describe this. We can also go that far that we write down the SVN 
revision number into the release notes. Then they are really tied 
strictly to this release and nothing else.



We can then have a "latest information", which are live in wiki.


What about to put a link like this at the top of the release notes to 
give it more visible attention:


Text: "For the latest information about Apache OpenOffice 4.0 see
  this related Wiki page."
Link: http://wiki.openoffice.org/wiki/AOO400_Lastest_Info

Then new and important / noteable changes can be documented in the (more 
easily accessible) Wiki.


My 2 ct.

Marcus




Remember, even if the issue is not caused by AOO code, a new upgrade
to a dependent operating system or other 3rd party application can
cause new issues to appear at any time.  So keeping  the release notes
updated is important.



This issue is highly caused by AOO code, remember the release code is
tested with a given set of third party libraries and given versions of the
operating systems.

Release notes reflect the environment tested for the 4.0 release,
everything that comes later should either be kept in a separate document or
postponed to a new release.




Do we lose anything if we do this?  For example, is there a concern
that the wiki can not handle the load?



Wiki can handle the load (it must because a lot of people will search for
info).

Yes we loose trackability. Release notes is in svn (in my opinion).
Remember in wiki anybody can change, so if person X test AOO on platform Y
should he/she  then just update the release documentation, I hope not.

But again, your idea of a live document is good, I just see it as a second
document (similar to what a lot of companies does).


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

Re: Where to keep release notes?

[Rob Weir]

On Jul 12, 2013, at 1:18 PM, janI  wrote:

> On 12 July 2013 18:49, Rob Weir  wrote:
>
>> In the past we drafted release notes on the wiki, and then moved them
>> to a location on the website.  I'd like to challenge our thinking on
>> this.
>>
>> Wouldn't it be useful to keep the release notes as a "live" document
>> on the wiki, so we can easily update it with additional information on
>> known issues as they are found, especially after release?
>
> I see your point, however I disagree.
>
> I think the release doc. for 4.0 is part of the release and should be
> frozen in svn like all other release artifacts. This is done by having it
> as a static web page.
>

It may be in SVN but it is not part of the release in any formal sense.


> We can then have a "latest information", which are live in wiki.
>

That could work, especially if we gave a  prominent link from the
Release Notes to the "latest info" wiki page.

-Rob


>
>>
>> Remember, even if the issue is not caused by AOO code, a new upgrade
>> to a dependent operating system or other 3rd party application can
>> cause new issues to appear at any time.  So keeping  the release notes
>> updated is important.
>
> This issue is highly caused by AOO code, remember the release code is
> tested with a given set of third party libraries and given versions of the
> operating systems.
>
> Release notes reflect the environment tested for the 4.0 release,
> everything that comes later should either be kept in a separate document or
> postponed to a new release.
>

That is logical, but I'm not sure the user (the target audience for
the Release Notes) would see it the same way. They only care about
accurate info related to their platform and configuration.   The less
searching they can do to find this info, the better.

>
>>
>> Do we lose anything if we do this?  For example, is there a concern
>> that the wiki can not handle the load?
>
> Wiki can handle the load (it must because a lot of people will search for
> info).
>
> Yes we loose trackability. Release notes is in svn (in my opinion).
> Remember in wiki anybody can change, so if person X test AOO on platform Y
> should he/she  then just update the release documentation, I hope not.
>
> But again, your idea of a live document is good, I just see it as a second
> document (similar to what a lot of companies does).
>
> rgds
> jan I.
>
>
>>
>> -Rob
>>
>> -
>> 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: Where to keep release notes?

[janI]

On 12 July 2013 18:49, Rob Weir  wrote:

> In the past we drafted release notes on the wiki, and then moved them
> to a location on the website.  I'd like to challenge our thinking on
> this.
>
> Wouldn't it be useful to keep the release notes as a "live" document
> on the wiki, so we can easily update it with additional information on
> known issues as they are found, especially after release?
>

I see your point, however I disagree.

I think the release doc. for 4.0 is part of the release and should be
frozen in svn like all other release artifacts. This is done by having it
as a static web page.

We can then have a "latest information", which are live in wiki.


>
> Remember, even if the issue is not caused by AOO code, a new upgrade
> to a dependent operating system or other 3rd party application can
> cause new issues to appear at any time.  So keeping  the release notes
> updated is important.
>

This issue is highly caused by AOO code, remember the release code is
tested with a given set of third party libraries and given versions of the
operating systems.

Release notes reflect the environment tested for the 4.0 release,
everything that comes later should either be kept in a separate document or
postponed to a new release.


>
> Do we lose anything if we do this?  For example, is there a concern
> that the wiki can not handle the load?
>

Wiki can handle the load (it must because a lot of people will search for
info).

Yes we loose trackability. Release notes is in svn (in my opinion).
Remember in wiki anybody can change, so if person X test AOO on platform Y
should he/she  then just update the release documentation, I hope not.

But again, your idea of a live document is good, I just see it as a second
document (similar to what a lot of companies does).

rgds
jan I.


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

Re: [VOTE]: Release OpenOffice 4.0 (RC)

[Armin Le Grand]

Hi List,

I have now played with a self-build pro AOO400 for two days, had no 
crash ;-)


+1

Sincerely,
Armin

On 12.07.2013 11:11, Jürgen Schmidt wrote:

Hi all,

this is a call for vote on releasing the following release candidate as
Apache OpenOffice 4.0. This will be an important release for Apache
OpenOffice with bigger visible UI changes. It is a key milestone to
continue the success of OpenOffice.

This release candidate provides the following important changes compared
to former OpenOffice releases:

(1) a major UI change/improvement by introducing a new sidebar concept
where the idea is the comes from IBM's Symphony. It's the combination of
reimplementing a complete new framework for sidebars and merging the
existing sidebar in impress and code of various content panels from the
Symphony grant in OpenOffice.

(2) 190 fixes from Symphony are merged and integrated, mainly
interoperability issues

(3) 600 defects are fixed

(4) many more features and improvements are integrated

For a detailed feature overview please see the release notes under
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes.
But keep in mind that the release notes are not yet final and will be
updated and polished ...

The release candidate artifacts (source release, as well as binary
releases for 23 languages) and further information how to verify and
review Apache OpenOffice 4.0 can be found on the following wiki page:

https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshot

The related RAT scan for this RC can be found under
http://people.apache.org/~jsc/aoo-4.0.0_rat/aoo-4.0.0_rat-output.html

The RC is based on the release branch AOO400, revision 1502185!

Please vote on releasing this package as Apache OpenOffice 4.0.

The vote starts now and will be open until:

UTC at noon on Monday, 15 July: 2013-07-15 12:00 UTC.

But we invite all people to vote (non binding) on this RC. We would like
to provide a release that is supported by the majority of our project
members.

[ ] +1 Release this package as Apache OpenOffice 4.0
[ ]  0 Don't care
[ ] -1 Do not release this package because...

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


--
ALG

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

Re: [VOTE]: Release OpenOffice 4.0 (RC)

[V Stuart Foote]

+1 -- buildbot nightlys have been solid for some time.

Still a number of resolved showstoppers ought to be verified, if anyone is
inclined to help knock a few out:

https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&namedcmd=4.0.0_release_blocker%2B%2C%20Resolved&Bugzilla_restrictlogin=on&sharer_id=251929&list_id=72815&remaction=run

But that is a QA crossing t's and dotting i's effort. The issues are fixed.

Otherwise mostly just polishing and Poodle tweaks for L10n support between
now and a final release.

Personally it's ready, let's get it out the door so we can move on to the
good stuff coming at 4.1, e.g. ia2 branch integration for full IAccessible2
support.


Juergen Schmidt wrote
> ...
> 
> Please vote on releasing this package as Apache OpenOffice 4.0.
> 
> The vote starts now and will be open until:
> 
>UTC at noon on Monday, 15 July: 2013-07-15 12:00 UTC.
> 
> But we invite all people to vote (non binding) on this RC. We would like
> to provide a release that is supported by the majority of our project
> members.
> 
>[ ] +1 Release this package as Apache OpenOffice 4.0
>[ ]  0 Don't care
>[ ] -1 Do not release this package because...





--
View this message in context: 
http://openoffice.2283327.n4.nabble.com/VOTE-Release-OpenOffice-4-0-RC-tp4647589p4647630.html
Sent from the Development mailing list archive at Nabble.com.

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

Where to keep release notes?

[Rob Weir]

In the past we drafted release notes on the wiki, and then moved them
to a location on the website.  I'd like to challenge our thinking on
this.

Wouldn't it be useful to keep the release notes as a "live" document
on the wiki, so we can easily update it with additional information on
known issues as they are found, especially after release?

Remember, even if the issue is not caused by AOO code, a new upgrade
to a dependent operating system or other 3rd party application can
cause new issues to appear at any time.  So keeping  the release notes
updated is important.

Do we lose anything if we do this?  For example, is there a concern
that the wiki can not handle the load?

-Rob

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

Re: [DISCUSS][VOTE]: Release OpenOffice 4.0 (RC)

[Ariel Constenla-Haile]

On Fri, Jul 12, 2013 at 12:48 PM, Rob Weir  wrote:
> Does anyone have a script to verify signatures and hashes for a release?
>
> In previous releases I'd download everything and do some ad-hoc
> commands, but not as automated as it could be.  Since we have a
> regular directory structure it should be possible to have a script
> that would verify everything and produce a report.

unless you are trying to verify the download, there is no need to
download anything, just ssh to people.apache.org and check the
integrity in place once moved to the  /www/www.apache.org/dist/
folder.
Something like:

arielch@~$ for i in
/home/jsc/public_html/developer-snapshots/RC/4.0.0/binaries/*/*.asc ;
do echo "Checking $i" && gpg2 --verify $i;done


Regards

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

Re: [RELEASE]: OpenOffice 4.0 RC availability

[Kay Schenk]

On Fri, Jul 12, 2013 at 7:38 AM, Ariel Constenla-Haile
wrote:

> On Fri, Jul 12, 2013 at 5:54 AM, Jürgen Schmidt 
> wrote:
> > Hi,
> >
> > the preparation of an OepnOffice 4.0 RC is nearly finished and the
> > upload is currently ongoing.
> >
> > Mac and Windows are already available and the source release as well.
> > Linux upload is also ongoing but not yet finished.
>
> 64 bit packages are ready. 32 bit packages are still being uploaded.
>
>
>
> Regards
>

YAY! Ok, Ariel I will keep an eye open for 32 bit! :) ...on to final testing

Great work by everyone!



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


-- 
-
MzK

"Every day we should hear at least one little song,
 read one good poem, see one exquisite picture,
 and, if possible, speak a few sensible words."
 -- Johann Wolfgang von Goethe

Re: Building From Eclipse

[Kay Schenk]

On Fri, Jul 12, 2013 at 2:20 AM, Andre Fischer  wrote:

> On 12.07.2013 10:54, Ajay Bhat wrote:
>
>> Hi,
>>
>> I'm using the Eclipse IDE for development and I've svn checked out the
>> OpenOffice trunk files. Can anyone give me a quick guide or point me to a
>> link to building in Eclipse as its not mentioned here
>> http://wiki.openoffice.org/**wiki/Documentation/Building_**Guide_AOO
>> ?
>>
>
> I think that at the moment nobody know how that works or if it works at
> all.
>

Hello Ajay, and yes to confirm Andre's comments. I would LOVE to know how
to do this myself. I think if you configured a custom "build script" -- we
use build.pl, you MIGHT get something going. Due to AOO's size, I think you
would need a machine with a good amount of memory, maybe 8 MB  -- I only
have 4 MB now and have difficulty doing some Eclipse operations on the
source --  and upping your JVM memory usage for sure.

However, I remember having seen a blog post by about building mozilla with
> eclipse.  It involved a lot of tweaking of eclipse's parameters like
> enlarging the amount of memory to the JVM and fiddling with CDT's
> parameters for scanning C++ files.  I will try to find the link but that
> may take some days.
>
> The general steps would be:
>
> - Create a new (C++) project from the SVN repository.
>
> - Let eclipse download the source code.
>
> - Let CDT scan all C/C++ source files.
>
> - Wrap AOO's build command into an Ant file.
>
> - Hit the button to build AOO
>
>
> I guess that wrapping the build command into an Ant file is the hardest
> part.
>
>
> -Andre
>
>
>> Thanks,
>>
>> Ajay
>>
>>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
-
MzK

"Every day we should hear at least one little song,
 read one good poem, see one exquisite picture,
 and, if possible, speak a few sensible words."
 -- Johann Wolfgang von Goethe

Re: [DISCUSS][VOTE]: Release OpenOffice 4.0 (RC)

[janI]

On Jul 12, 2013 5:12 PM, "Ariel Constenla-Haile"  wrote:
>
> On Fri, Jul 12, 2013 at 12:00 PM, Raphael Bircher 
wrote:
> > The point is, who has desided to make a RC? I don't find a single
> > discoussion about it. A RC should be discused on the list. I know, there
> > where serios testings, but for my point of view not enoght. IA2 is
> > integrated same days befor, so the QA has no chance to find regressions
to
> > this part of code.
>
> What are you talking about? IA2 has not been integrated, not a single
line.
>
> > I work with 4.0 since same week. It is not bad, but I personaly think
there
> > are still same serios bugs in.
>
> Then you should submit bugs in bugzilla; but this statement
> contradicts the one below: if you think there are serious bugs, you
> don't need to search them, you should already know them.
>
> > Well, I can nothing else do as search same showstoper for RC1. But even
I
> > don't find one, I will vote -1. I'm sorry, I can't put my name under a
> > Release under this condition.

+1 from me, I know there are still ñroblems to be solved, but in a year
from now we will also have problems let get a RC out, and move on.

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

Re: [DISCUSS][VOTE]: Release OpenOffice 4.0 (RC)

[Rob Weir]

Does anyone have a script to verify signatures and hashes for a release?

In previous releases I'd download everything and do some ad-hoc
commands, but not as automated as it could be.  Since we have a
regular directory structure it should be possible to have a script
that would verify everything and produce a report.

Does anyone have something like this?

-Rob

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

Re: [DISCUSS][VOTE]: Release OpenOffice 4.0 (RC)

[Ariel Constenla-Haile]

On Fri, Jul 12, 2013 at 12:00 PM, Raphael Bircher  wrote:
> The point is, who has desided to make a RC? I don't find a single
> discoussion about it. A RC should be discused on the list. I know, there
> where serios testings, but for my point of view not enoght. IA2 is
> integrated same days befor, so the QA has no chance to find regressions to
> this part of code.

What are you talking about? IA2 has not been integrated, not a single line.

> I work with 4.0 since same week. It is not bad, but I personaly think there
> are still same serios bugs in.

Then you should submit bugs in bugzilla; but this statement
contradicts the one below: if you think there are serious bugs, you
don't need to search them, you should already know them.

> Well, I can nothing else do as search same showstoper for RC1. But even I
> don't find one, I will vote -1. I'm sorry, I can't put my name under a
> Release under this condition.


Regards

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

Re: [DISCUSS][VOTE]: Release OpenOffice 4.0 (RC)

[Raphael Bircher]

Am 12.07.13 16:32, schrieb Jürgen Schmidt:

What is not serious that I plan a 72 hr vote that is normal at Apache?
We are not loner an incubator project and 72 hr are enough. The RC is
not so much different than the snapshot before.
The point is, who has desided to make a RC? I don't find a single 
discoussion about it. A RC should be discused on the list. I know, there 
where serios testings, but for my point of view not enoght. IA2 is 
integrated same days befor, so the QA has no chance to find regressions 
to this part of code.


I work with 4.0 since same week. It is not bad, but I personaly think 
there are still same serios bugs in. You can't find this potential 
Errors within 72 hours.


I find it wrong to annonce a RC without public discoussion if the 
Version is RC ready. And the stabilization phase was far to short.


Well, I can nothing else do as search same showstoper for RC1. But even 
I don't find one, I will vote -1. I'm sorry, I can't put my name under a 
Release under this condition.


Greetings Raphael



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

Re: [DISCUSS][VOTE]: Release OpenOffice 4.0 (RC)

[Rob Weir]

On Fri, Jul 12, 2013 at 11:00 AM, Raphael Bircher  wrote:
> Am 12.07.13 16:32, schrieb Jürgen Schmidt:
>
>> What is not serious that I plan a 72 hr vote that is normal at Apache?
>> We are not loner an incubator project and 72 hr are enough. The RC is
>> not so much different than the snapshot before.
>
> The point is, who has desided to make a RC? I don't find a single
> discoussion about it. A RC should be discused on the list. I know, there

The detailed proposal and discussion was in this thread, from June
19th,  three weeks ago:

http://markmail.org/message/4wzawtnxaruvztqm

-Rob


> where serios testings, but for my point of view not enoght. IA2 is
> integrated same days befor, so the QA has no chance to find regressions to
> this part of code.
>
> I work with 4.0 since same week. It is not bad, but I personaly think there
> are still same serios bugs in. You can't find this potential Errors within
> 72 hours.
>
> I find it wrong to annonce a RC without public discoussion if the Version is
> RC ready. And the stabilization phase was far to short.
>
> Well, I can nothing else do as search same showstoper for RC1. But even I
> don't find one, I will vote -1. I'm sorry, I can't put my name under a
> Release under this condition.
>
> Greetings Raphael
>
>
>
>
> -
> 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

Upgrading over 3.4.x

[Rob Weir]

I've been doing some extra testing of the AOO 4.0 install over OOo
3.3.0/AOO 3.4.0 and AOO 3.4.1.  I also looked at the install over LO
4.0 to makes sure that is clean as well.

So far everything looks great.

One thing I wanted to verify was this directory:


C:\Program Files\OpenOffice.org 3\share\uno_packages\cache\uno_packages

I found that this empty directory was left behind after an upgrade.

Is it safe to delete?  Will it always be empty?

I'm thinking of adding a section to the release notes on the upgrade
processing and saying that it is safe to delete that directory, as
well as the installation files from earlier versions, e.g.:
OpenOffice.org 3.4.1 (en-US) Installation Files or  OpenOffice.org 3.3
(en-US) Installation Files.


Regards,

-Rob

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

Re: Building in recent environments: Java 7 and Mozilla

[Ariel Constenla-Haile]

On Tue, Jul 2, 2013 at 3:10 AM, Andrea Pescetti  wrote:
> I tried building OpenOffice on the coming Fedora 19 to see how it worked
> with a fairly recent set of build tools. As for STLport, I used the default
> choice for 32-bit systems (this uses the STLPort package from the external
> sources we bundle).

Don't know why this was left as the default, but the de-facto is to
configure with --without-stlport (this is what is done for the
release).

> We have two problems with the current trunk:

I had no problems building today on F19:
~]$ g++ --version
g++ (GCC) 4.8.1 20130603 (Red Hat 4.8.1-1)


Regards

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

Re: [RELEASE]: OpenOffice 4.0 RC availability

[Ariel Constenla-Haile]

On Fri, Jul 12, 2013 at 5:54 AM, Jürgen Schmidt  wrote:
> Hi,
>
> the preparation of an OepnOffice 4.0 RC is nearly finished and the
> upload is currently ongoing.
>
> Mac and Windows are already available and the source release as well.
> Linux upload is also ongoing but not yet finished.

64 bit packages are ready. 32 bit packages are still being uploaded.



Regards

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

[DISCUSS][VOTE]: Release OpenOffice 4.0 (RC)

[Jürgen Schmidt]

What is not serious that I plan a 72 hr vote that is normal at Apache?
We are not loner an incubator project and 72 hr are enough. The RC is
not so much different than the snapshot before.

You can vote -1 if you want but I hope that you take it serious and
don't vote simply and without any real argument. The argument that "you"
would need more time is not valid for me.

It's always interesting to see such comments in the end phase. But what
do you think did we over the past weeks?

We analyzed bugs, problems, fixed all serious ones and continue general
testing. I proposed a release schedule, proposed an update and we
continue to work hard to achieve this date. Some continuity in the
things we propose and announce is not a bad thing. If we detect serious
problems we can always take the necessary actions.

Let us concentrate on the end game ... We still have some things to do
and the polishing and completion of the release notes is one thing.

If you disagree to the proposed schedule you should have raised your
concerns a little bit earlier.

Juergen


On 7/12/13 3:43 PM, Rob Weir wrote:
> On Fri, Jul 12, 2013 at 9:23 AM, Raphael Bircher  wrote:
>> Hi at all
>>
>> Moment Jürgen. Test a RC and final vote. within 72 houers is unserios. Pleas
>> give a a full week for this. Else i will vote -1 because there is not
>> enought time to make the final tests.
>>
> 
> The previous dev snapshot (rev. 1499347)  build was July 5th.  That
> was 8 days ago.  So there has been over a week for anyone who was
> interested in doing more testing or reporting any new release
> blockers.
> 
> With the RC I think we can be more focused and verify the fixed bugs
> and test around any areas that changed since the last dev snapshot.
> 
> (Think of it this way:  If Juergen had labeled the July 5th dev
> snapshot as "RC 1" and today's build as "RC 2", would any more testing
> have occurred?  Would anything be different?)
> 
> Regards,
> 
> -Rob
> 
> 
>> Greetings Raphael
>>
>> Am 12.07.13 11:11, schrieb Jürgen Schmidt:
>>
>>> Hi all,
>>>
>>> this is a call for vote on releasing the following release candidate as
>>> Apache OpenOffice 4.0. This will be an important release for Apache
>>> OpenOffice with bigger visible UI changes. It is a key milestone to
>>> continue the success of OpenOffice.
>>>
>>> This release candidate provides the following important changes compared
>>> to former OpenOffice releases:
>>>
>>> (1) a major UI change/improvement by introducing a new sidebar concept
>>> where the idea is the comes from IBM's Symphony. It's the combination of
>>> reimplementing a complete new framework for sidebars and merging the
>>> existing sidebar in impress and code of various content panels from the
>>> Symphony grant in OpenOffice.
>>>
>>> (2) 190 fixes from Symphony are merged and integrated, mainly
>>> interoperability issues
>>>
>>> (3) 600 defects are fixed
>>>
>>> (4) many more features and improvements are integrated
>>>
>>> For a detailed feature overview please see the release notes under
>>>
>>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes.
>>> But keep in mind that the release notes are not yet final and will be
>>> updated and polished ...
>>>
>>> The release candidate artifacts (source release, as well as binary
>>> releases for 23 languages) and further information how to verify and
>>> review Apache OpenOffice 4.0 can be found on the following wiki page:
>>>
>>>
>>> https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshot
>>>
>>> The related RAT scan for this RC can be found under
>>> http://people.apache.org/~jsc/aoo-4.0.0_rat/aoo-4.0.0_rat-output.html
>>>
>>> The RC is based on the release branch AOO400, revision 1502185!
>>>
>>> Please vote on releasing this package as Apache OpenOffice 4.0.
>>>
>>> The vote starts now and will be open until:
>>>
>>> UTC at noon on Monday, 15 July: 2013-07-15 12:00 UTC.
>>>
>>> But we invite all people to vote (non binding) on this RC. We would like
>>> to provide a release that is supported by the majority of our project
>>> members.
>>>
>>> [ ] +1 Release this package as Apache OpenOffice 4.0
>>> [ ]  0 Don't care
>>> [ ] -1 Do not release this package because...
>>>
>>> -
>>> 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
> 


-
To unsubs

Testing for OpenOffice 4.0 (RC) Start! Call for volunteers!

[Yuzhen Fan]

Hi All,

The Release Candidate build is just announced, and we can start doing RC
acceptance test now. This is the call for volunteers on the final tests.
Any one who can contribute to the testing, please send me your TestLink ID
and preferred platforms, and I will assign test cases to you.

The test plan is ready with test cases having been added in TestLink, here
is the test guidance[1]. Please note, the RC is based on the release branch
AOO400, revision 1502185.


[1]
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+RC+Acceptance+Test+Guidance

Regards,
Yu Zhen



On Fri, Jul 12, 2013 at 9:34 PM, Shenfeng Liu  wrote:

> Thanks for the report, Yu Zhen!
>
> Juergen just annoucned the RC build. Let's call for volunteers and start
> the RC build testing!
>
> - Shenfeng (Simon)
>
>
> 2013/7/12 Yuzhen Fan 
>
> > Hi All,
> >
> > We continue doing the AOO 4.0 Final Regression test this week as well as
> > the defect verification, here is the weekly update (07/08 - 07/12):
> >
> > *Test execution:*
> > 1.  Final Regression test
> > We have assigned 1804 text executions to about 20 volunteers, and
> completed
> > about 68% in execution (1221 test executions done). We are closing this
> > test window this week
> >
> > Sub TotalAssignedNot Assigned
> > SubTotalRunNot Run
> > Mac66446136695203
> > Win75254423529083
> > Redhat5145141283860
> > Ubuntu37537537500
> > Debian12120120
> > Total209018041221583286
> >
> > 2. Release candidate acceptance test - test plan is ready, wait for RC
> > build, test guidance here:
> >
> >
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+RC+Acceptance+Test+Guidance
> >
> > *Defect summary:*
> > 1. Defect verification(with flag 4.0.0_release_blocker+) : there are 59
> > bugs in backlog now, among of them, 31 are for translation, 11 are for
> > code, which need actions from native reporters and development,
> > respectively
> >
> > Accomplished this week (only for Function UI)
> >
> > Verified/FixedReopendWait for buildLook for env/platform
>  New
> > fixed/added in backlog
> > 182548
> >
> > Backlog at end of this week
> >
> > TotalL10NFunction CodeFunction UI
> > 59311117
> >
> > *Issues & quality highlight:*
> > 1. We need to clean up 59 resolved/fixed release blocker defects, there
> is
> > gap on translation defects' verification
> > 2. Some of these defects were late changes, and we may have to wait for
> RC
> > to verify some of them
> > *
> > Volunteer status: *
> > 1. No volunteers are for left translation defects' verification
> > 2. No new volunteers(total 20 so far) on test execution work
> > 3. 2 volunteers are on defect verification work, make little progress
> > *
> > Plan for next week:*
>  > 1. Work with volunteers to verify defects as release blocker (total 59)
> > 2. Continue to do Drawing exploration test on Mac and Linux
> > 3. Start to do RC acceptance test providing RC build is ready
> >
> > Thanks you all for effort this week, we are towards to the release
> > candidate of AOO 4.0, let's continue and make progress next week!
> >
> > Regards,
> > Yu Zhen
> >
>

[DISCUSS][VOTE]: Release OpenOffice 4.0 (RC)

[Jürgen Schmidt]

please don't discuss in a vote thread


@Raphael, I disagree we do testing on snapshots since weeks.

Juergen


On 7/12/13 3:43 PM, Rob Weir wrote:
> On Fri, Jul 12, 2013 at 9:23 AM, Raphael Bircher  wrote:
>> Hi at all
>>
>> Moment Jürgen. Test a RC and final vote. within 72 houers is unserios. Pleas
>> give a a full week for this. Else i will vote -1 because there is not
>> enought time to make the final tests.
>>
> 
> The previous dev snapshot (rev. 1499347)  build was July 5th.  That
> was 8 days ago.  So there has been over a week for anyone who was
> interested in doing more testing or reporting any new release
> blockers.
> 
> With the RC I think we can be more focused and verify the fixed bugs
> and test around any areas that changed since the last dev snapshot.
> 
> (Think of it this way:  If Juergen had labeled the July 5th dev
> snapshot as "RC 1" and today's build as "RC 2", would any more testing
> have occurred?  Would anything be different?)
> 
> Regards,
> 
> -Rob
> 
> 
>> Greetings Raphael
>>
>> Am 12.07.13 11:11, schrieb Jürgen Schmidt:
>>
>>> Hi all,
>>>
>>> this is a call for vote on releasing the following release candidate as
>>> Apache OpenOffice 4.0. This will be an important release for Apache
>>> OpenOffice with bigger visible UI changes. It is a key milestone to
>>> continue the success of OpenOffice.
>>>
>>> This release candidate provides the following important changes compared
>>> to former OpenOffice releases:
>>>
>>> (1) a major UI change/improvement by introducing a new sidebar concept
>>> where the idea is the comes from IBM's Symphony. It's the combination of
>>> reimplementing a complete new framework for sidebars and merging the
>>> existing sidebar in impress and code of various content panels from the
>>> Symphony grant in OpenOffice.
>>>
>>> (2) 190 fixes from Symphony are merged and integrated, mainly
>>> interoperability issues
>>>
>>> (3) 600 defects are fixed
>>>
>>> (4) many more features and improvements are integrated
>>>
>>> For a detailed feature overview please see the release notes under
>>>
>>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes.
>>> But keep in mind that the release notes are not yet final and will be
>>> updated and polished ...
>>>
>>> The release candidate artifacts (source release, as well as binary
>>> releases for 23 languages) and further information how to verify and
>>> review Apache OpenOffice 4.0 can be found on the following wiki page:
>>>
>>>
>>> https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshot
>>>
>>> The related RAT scan for this RC can be found under
>>> http://people.apache.org/~jsc/aoo-4.0.0_rat/aoo-4.0.0_rat-output.html
>>>
>>> The RC is based on the release branch AOO400, revision 1502185!
>>>
>>> Please vote on releasing this package as Apache OpenOffice 4.0.
>>>
>>> The vote starts now and will be open until:
>>>
>>> UTC at noon on Monday, 15 July: 2013-07-15 12:00 UTC.
>>>
>>> But we invite all people to vote (non binding) on this RC. We would like
>>> to provide a release that is supported by the majority of our project
>>> members.
>>>
>>> [ ] +1 Release this package as Apache OpenOffice 4.0
>>> [ ]  0 Don't care
>>> [ ] -1 Do not release this package because...
>>>
>>> -
>>> 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
> 


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

Re: [VOTE]: Release OpenOffice 4.0 (RC)

[Rob Weir]

On Fri, Jul 12, 2013 at 9:23 AM, Raphael Bircher  wrote:
> Hi at all
>
> Moment Jürgen. Test a RC and final vote. within 72 houers is unserios. Pleas
> give a a full week for this. Else i will vote -1 because there is not
> enought time to make the final tests.
>

The previous dev snapshot (rev. 1499347)  build was July 5th.  That
was 8 days ago.  So there has been over a week for anyone who was
interested in doing more testing or reporting any new release
blockers.

With the RC I think we can be more focused and verify the fixed bugs
and test around any areas that changed since the last dev snapshot.

(Think of it this way:  If Juergen had labeled the July 5th dev
snapshot as "RC 1" and today's build as "RC 2", would any more testing
have occurred?  Would anything be different?)

Regards,

-Rob


> Greetings Raphael
>
> Am 12.07.13 11:11, schrieb Jürgen Schmidt:
>
>> Hi all,
>>
>> this is a call for vote on releasing the following release candidate as
>> Apache OpenOffice 4.0. This will be an important release for Apache
>> OpenOffice with bigger visible UI changes. It is a key milestone to
>> continue the success of OpenOffice.
>>
>> This release candidate provides the following important changes compared
>> to former OpenOffice releases:
>>
>> (1) a major UI change/improvement by introducing a new sidebar concept
>> where the idea is the comes from IBM's Symphony. It's the combination of
>> reimplementing a complete new framework for sidebars and merging the
>> existing sidebar in impress and code of various content panels from the
>> Symphony grant in OpenOffice.
>>
>> (2) 190 fixes from Symphony are merged and integrated, mainly
>> interoperability issues
>>
>> (3) 600 defects are fixed
>>
>> (4) many more features and improvements are integrated
>>
>> For a detailed feature overview please see the release notes under
>>
>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes.
>> But keep in mind that the release notes are not yet final and will be
>> updated and polished ...
>>
>> The release candidate artifacts (source release, as well as binary
>> releases for 23 languages) and further information how to verify and
>> review Apache OpenOffice 4.0 can be found on the following wiki page:
>>
>>
>> https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshot
>>
>> The related RAT scan for this RC can be found under
>> http://people.apache.org/~jsc/aoo-4.0.0_rat/aoo-4.0.0_rat-output.html
>>
>> The RC is based on the release branch AOO400, revision 1502185!
>>
>> Please vote on releasing this package as Apache OpenOffice 4.0.
>>
>> The vote starts now and will be open until:
>>
>> UTC at noon on Monday, 15 July: 2013-07-15 12:00 UTC.
>>
>> But we invite all people to vote (non binding) on this RC. We would like
>> to provide a release that is supported by the majority of our project
>> members.
>>
>> [ ] +1 Release this package as Apache OpenOffice 4.0
>> [ ]  0 Don't care
>> [ ] -1 Do not release this package because...
>>
>> -
>> 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: [QA][Test Report] Weekly Status Update as of 20130712

[Shenfeng Liu]

Thanks for the report, Yu Zhen!

Juergen just annoucned the RC build. Let's call for volunteers and start
the RC build testing!

- Shenfeng (Simon)


2013/7/12 Yuzhen Fan 

> Hi All,
>
> We continue doing the AOO 4.0 Final Regression test this week as well as
> the defect verification, here is the weekly update (07/08 - 07/12):
>
> *Test execution:*
> 1.  Final Regression test
> We have assigned 1804 text executions to about 20 volunteers, and completed
> about 68% in execution (1221 test executions done). We are closing this
> test window this week
>
> Sub TotalAssignedNot Assigned
> SubTotalRunNot Run
> Mac66446136695203
> Win75254423529083
> Redhat5145141283860
> Ubuntu37537537500
> Debian12120120
> Total209018041221583286
>
> 2. Release candidate acceptance test - test plan is ready, wait for RC
> build, test guidance here:
>
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+RC+Acceptance+Test+Guidance
>
> *Defect summary:*
> 1. Defect verification(with flag 4.0.0_release_blocker+) : there are 59
> bugs in backlog now, among of them, 31 are for translation, 11 are for
> code, which need actions from native reporters and development,
> respectively
>
> Accomplished this week (only for Function UI)
>
> Verified/FixedReopendWait for buildLook for env/platformNew
> fixed/added in backlog
> 182548
>
> Backlog at end of this week
>
> TotalL10NFunction CodeFunction UI
> 59311117
>
> *Issues & quality highlight:*
> 1. We need to clean up 59 resolved/fixed release blocker defects, there is
> gap on translation defects' verification
> 2. Some of these defects were late changes, and we may have to wait for RC
> to verify some of them
> *
> Volunteer status: *
> 1. No volunteers are for left translation defects' verification
> 2. No new volunteers(total 20 so far) on test execution work
> 3. 2 volunteers are on defect verification work, make little progress
> *
> Plan for next week:*
> 1. Work with volunteers to verify defects as release blocker (total 59)
> 2. Continue to do Drawing exploration test on Mac and Linux
> 3. Start to do RC acceptance test providing RC build is ready
>
> Thanks you all for effort this week, we are towards to the release
> candidate of AOO 4.0, let's continue and make progress next week!
>
> Regards,
> Yu Zhen
>

Re: [VOTE]: Release OpenOffice 4.0 (RC)

[Raphael Bircher]

Am 12.07.13 15:30, schrieb Shenfeng Liu:

Rapheal,
   I agree that the RC build should be tested.
   But I think rather than the time, what we really care should be what is
tested. I'm looking forward Yu Zhen(our QA lead)'s RC test plan. If we get
a satisfiable plan and the test can be finished within 3 days, I will give
my +1 immediately. More people helping the test, the faster we can get it
done and release 4.0 out.

- Shenfeng (Simon)


2013/7/12 Raphael Bircher 


Hi at all

Moment Jürgen. Test a RC and final vote. within 72 houers is unserios.
Pleas give a a full week for this. Else i will vote -1 because there is not
enought time to make the final tests.

Greetings Raphael

Am 12.07.13 11:11, schrieb Jürgen Schmidt:

  Hi all,

this is a call for vote on releasing the following release candidate as
Apache OpenOffice 4.0. This will be an important release for Apache
OpenOffice with bigger visible UI changes. It is a key milestone to
continue the success of OpenOffice.

This release candidate provides the following important changes compared
to former OpenOffice releases:

(1) a major UI change/improvement by introducing a new sidebar concept
where the idea is the comes from IBM's Symphony. It's the combination of
reimplementing a complete new framework for sidebars and merging the
existing sidebar in impress and code of various content panels from the
Symphony grant in OpenOffice.

(2) 190 fixes from Symphony are merged and integrated, mainly
interoperability issues

(3) 600 defects are fixed

(4) many more features and improvements are integrated

For a detailed feature overview please see the release notes under
https://cwiki.apache.org/**confluence/display/OOOUSERS/**
AOO+4.0+Release+Notes
.
But keep in mind that the release notes are not yet final and will be
updated and polished ...

The release candidate artifacts (source release, as well as binary
releases for 23 languages) and further information how to verify and
review Apache OpenOffice 4.0 can be found on the following wiki page:

https://cwiki.apache.org/**confluence/display/OOOUSERS/**
Development+Snapshot+Builds#**DevelopmentSnapshotBuilds-**AOOSnapshot

The related RAT scan for this RC can be found under
http://people.apache.org/~jsc/**aoo-4.0.0_rat/aoo-4.0.0_rat-**output.html

The RC is based on the release branch AOO400, revision 1502185!

Please vote on releasing this package as Apache OpenOffice 4.0.

The vote starts now and will be open until:

 UTC at noon on Monday, 15 July: 2013-07-15 12:00 UTC.

But we invite all people to vote (non binding) on this RC. We would like
to provide a release that is supported by the majority of our project
members.

 [ ] +1 Release this package as Apache OpenOffice 4.0
 [ ]  0 Don't care
 [ ] -1 Do not release this package because...

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



--**--**-
To unsubscribe, e-mail: 
dev-unsubscribe@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: [VOTE]: Release OpenOffice 4.0 (RC)

[Shenfeng Liu]

Rapheal,
  I agree that the RC build should be tested.
  But I think rather than the time, what we really care should be what is
tested. I'm looking forward Yu Zhen(our QA lead)'s RC test plan. If we get
a satisfiable plan and the test can be finished within 3 days, I will give
my +1 immediately. More people helping the test, the faster we can get it
done and release 4.0 out.

- Shenfeng (Simon)


2013/7/12 Raphael Bircher 

> Hi at all
>
> Moment Jürgen. Test a RC and final vote. within 72 houers is unserios.
> Pleas give a a full week for this. Else i will vote -1 because there is not
> enought time to make the final tests.
>
> Greetings Raphael
>
> Am 12.07.13 11:11, schrieb Jürgen Schmidt:
>
>  Hi all,
>>
>> this is a call for vote on releasing the following release candidate as
>> Apache OpenOffice 4.0. This will be an important release for Apache
>> OpenOffice with bigger visible UI changes. It is a key milestone to
>> continue the success of OpenOffice.
>>
>> This release candidate provides the following important changes compared
>> to former OpenOffice releases:
>>
>> (1) a major UI change/improvement by introducing a new sidebar concept
>> where the idea is the comes from IBM's Symphony. It's the combination of
>> reimplementing a complete new framework for sidebars and merging the
>> existing sidebar in impress and code of various content panels from the
>> Symphony grant in OpenOffice.
>>
>> (2) 190 fixes from Symphony are merged and integrated, mainly
>> interoperability issues
>>
>> (3) 600 defects are fixed
>>
>> (4) many more features and improvements are integrated
>>
>> For a detailed feature overview please see the release notes under
>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
>> AOO+4.0+Release+Notes
>> .
>> But keep in mind that the release notes are not yet final and will be
>> updated and polished ...
>>
>> The release candidate artifacts (source release, as well as binary
>> releases for 23 languages) and further information how to verify and
>> review Apache OpenOffice 4.0 can be found on the following wiki page:
>>
>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
>> Development+Snapshot+Builds#**DevelopmentSnapshotBuilds-**AOOSnapshot
>>
>> The related RAT scan for this RC can be found under
>> http://people.apache.org/~jsc/**aoo-4.0.0_rat/aoo-4.0.0_rat-**output.html
>>
>> The RC is based on the release branch AOO400, revision 1502185!
>>
>> Please vote on releasing this package as Apache OpenOffice 4.0.
>>
>> The vote starts now and will be open until:
>>
>> UTC at noon on Monday, 15 July: 2013-07-15 12:00 UTC.
>>
>> But we invite all people to vote (non binding) on this RC. We would like
>> to provide a release that is supported by the majority of our project
>> members.
>>
>> [ ] +1 Release this package as Apache OpenOffice 4.0
>> [ ]  0 Don't care
>> [ ] -1 Do not release this package because...
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> dev-unsubscribe@openoffice.**apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Call for Translation Verification - Towards AOO 4.0 Release Candidate - 61 show stopper bugs are waiting for verification

[Shenfeng Liu]

Thanks Yu Zhen to drive the defect verification! It is very important to
ensure all release blocker defects are really fixed.

I noticed that there are 21 resolved release blockers are about
translations. So I forward to I10N mail list and suggest we contribute to
verify and close those items.

19 among the 21 are really feature/task to enable the languages in 4.0. I
suggest we following the way below to verify:
1. Install the native language package of the AOO 4.0 RC build from
here
.
2. Lauch the AOO 4.0 RC application, verify (1) the translation language in
this package is correct; (2) new or open a document to check the basic
functions not impacted.
3. If the verification in step 2 passed, please add comments in related
Bugzilla record and change the status to VERIIFIED.
4. If any string need to be refined, you can open a new defect in Bugzilla.

Below is the 19 records per my current check:
121816 Native-L pt Portuguese (pt) translation update fro AOO
4.0
122284 Native-L ru Russian (ru) translation for OpenOffice 4.x
122355 Native-L sk Slovak (sk) translation for OpenOffice 4.x
122360 Native-L hu Hungarian translation of AOO 4.0.0
122386 Native-L sl Slovenian (sl) translation for OpenOffice 4.x
122457 Native-L es [ES]Integrate last Spanish 4.0 translation
122467 Native-L nl Dutch translation for AOO 4.0
122468 Native-L de German translation update for AOO 4.0
122469 Native-L en-GB English (United Kingdom) translation
update for AOO 4.0
122474 Native-L ja Japanese (ja) translation for for OpenOffice
4.x
122488 Native-L ko Korean translation of AOO 4.0 UI & Help
122568 Native-L fi Finnish translation update for AOO 4.0
122584 Native-L fr French translation update for AOO4.0
122585 Native-L ta Tamil translation for AOO 4.0
122588 Native-L it Italian translation update for AOO 4.0
122631 Native-L gd Gaelic (gd) translation for OpenOffice 4.x
122653 Native-L el Greek (el) translation for OpenOffice 4.x
122670 Native-L ast Asturian translation update for AOO 4.0
122689 Native-L gl Galician translation update for AOO 4.0


The 2 below will require special check:
122192 Native-L pt-br Some strings directing to Oracle
122640 Native-L it Accelerators (mnemonics) missing in main
menu in localized versions


Any comments?
Thanks!

- Shenfeng (Simon)




2013/7/11 Yuzhen Fan 

> Dear all,
>
> We have verified 20 resolved show stopper bugs since this Monday(July 8),
> there are now *61 *bugs in backlog which need us to do the verification as
> soon as possible.
>
> If you have a piece of time, please pick up your interested bugs from this
> list to verify. If you are the reporters for the bugs, it may only take
> your about 10 minutes for one bug.
>
>
> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=4.0.0_release_blocker%2B%2C%20Resolved&sharer_id=251929&list_id=72804
>
> Also, these bugs' fix are code related, the verification are expected from
> development.
>
>  Bug ID Product Component Assignee StatusResolution  Summary  122192
>  Native-Lang pt-br iss...@openoffice.apache.org RESOLVED FIXED Some
> strings
> directing to Oracle  122356  App Dev sdk j...@apache.org RESOLVED FIXED SDK
> broken after 3 layer removal  122444  Installation update notifications
> o...@apache.org RESOLVED FIXED Update Code to Reflect Final Update Server
> Destination for AOO 4.0  122478  General ui j...@apache.org RESOLVED
> FIXED Remaining
> of basis-link after 3-layer removal  122482  App Dev sdk j...@apache.org
> RESOLVED FIXED Impossible to build SDK C++ examples  122483  App Dev sdk
> j...@apache.org RESOLVED FIXED unoapploader sets wrong LD_LIBRARY_PATH
> 122500 Build Tools code o...@apache.org RESOLVED FIXED Impossible to build
> with Visual C++ 2008 Express Edition  122504 Installation code
> j...@apache.org RESOLVED FIXED Rename the source files to
> "apache-openoffice-..." to show clearly the affiliation for this project
> 122586 App Dev api j...@apache.org RESOLVED FIXED fix awt GridControl
> refresh
> 122647 General code h...@apache.org RESOLVED FIXED Python linked against
> system OpenSSL  122692 General code iss...@openoffice.apache.org RESOLVED
> FIXED boost build fixes for OS/2
>
> We are in the build of AOO 4.0 RC build now, your help means much to it!
>
> Regards,
> Yu Zhen
>

Re: [VOTE]: Release OpenOffice 4.0 (RC)

[Raphael Bircher]

Hi at all

Moment Jürgen. Test a RC and final vote. within 72 houers is unserios. 
Pleas give a a full week for this. Else i will vote -1 because there is 
not enought time to make the final tests.


Greetings Raphael

Am 12.07.13 11:11, schrieb Jürgen Schmidt:

Hi all,

this is a call for vote on releasing the following release candidate as
Apache OpenOffice 4.0. This will be an important release for Apache
OpenOffice with bigger visible UI changes. It is a key milestone to
continue the success of OpenOffice.

This release candidate provides the following important changes compared
to former OpenOffice releases:

(1) a major UI change/improvement by introducing a new sidebar concept
where the idea is the comes from IBM's Symphony. It's the combination of
reimplementing a complete new framework for sidebars and merging the
existing sidebar in impress and code of various content panels from the
Symphony grant in OpenOffice.

(2) 190 fixes from Symphony are merged and integrated, mainly
interoperability issues

(3) 600 defects are fixed

(4) many more features and improvements are integrated

For a detailed feature overview please see the release notes under
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes.
But keep in mind that the release notes are not yet final and will be
updated and polished ...

The release candidate artifacts (source release, as well as binary
releases for 23 languages) and further information how to verify and
review Apache OpenOffice 4.0 can be found on the following wiki page:

https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshot

The related RAT scan for this RC can be found under
http://people.apache.org/~jsc/aoo-4.0.0_rat/aoo-4.0.0_rat-output.html

The RC is based on the release branch AOO400, revision 1502185!

Please vote on releasing this package as Apache OpenOffice 4.0.

The vote starts now and will be open until:

UTC at noon on Monday, 15 July: 2013-07-15 12:00 UTC.

But we invite all people to vote (non binding) on this RC. We would like
to provide a release that is supported by the majority of our project
members.

[ ] +1 Release this package as Apache OpenOffice 4.0
[ ]  0 Don't care
[ ] -1 Do not release this package because...

-
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: [VOTE]: Release OpenOffice 4.0 (RC)

[FR web forum]

Hello,

>The release candidate artifacts (source release, as well as binary
>releases for 23 languages) and further information how to verify and
Is it possible to rebuild french language pack for this RC?
We have to do some changes to fix translation errors in Pootle.

However, +1
Thanks

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

Re: [VOTE]: Release OpenOffice 4.0 (RC)

[Marco A.G.Pinto]

  
  
+1
  
  On 12/07/2013 10:11, Jürgen Schmidt wrote:


  Hi all,

this is a call for vote on releasing the following release candidate as
Apache OpenOffice 4.0. This will be an important release for Apache
OpenOffice with bigger visible UI changes. It is a key milestone to
continue the success of OpenOffice.

This release candidate provides the following important changes compared
to former OpenOffice releases:

(1) a major UI change/improvement by introducing a new sidebar concept
where the idea is the comes from IBM's Symphony. It's the combination of
reimplementing a complete new framework for sidebars and merging the
existing sidebar in impress and code of various content panels from the
Symphony grant in OpenOffice.

(2) 190 fixes from Symphony are merged and integrated, mainly
interoperability issues

(3) 600 defects are fixed

(4) many more features and improvements are integrated

For a detailed feature overview please see the release notes under
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes.
But keep in mind that the release notes are not yet final and will be
updated and polished ...

The release candidate artifacts (source release, as well as binary
releases for 23 languages) and further information how to verify and
review Apache OpenOffice 4.0 can be found on the following wiki page:

https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshot

The related RAT scan for this RC can be found under
http://people.apache.org/~jsc/aoo-4.0.0_rat/aoo-4.0.0_rat-output.html

The RC is based on the release branch AOO400, revision 1502185!

Please vote on releasing this package as Apache OpenOffice 4.0.

The vote starts now and will be open until:

   UTC at noon on Monday, 15 July: 2013-07-15 12:00 UTC.

But we invite all people to vote (non binding) on this RC. We would like
to provide a release that is supported by the majority of our project
members.

   [ ] +1 Release this package as Apache OpenOffice 4.0
   [ ]  0 Don't care
   [ ] -1 Do not release this package because...




-- 
  
  

[QA][Test Report] Weekly Status Update as of 20130712

[Yuzhen Fan]

Hi All,

We continue doing the AOO 4.0 Final Regression test this week as well as
the defect verification, here is the weekly update (07/08 - 07/12):

*Test execution:*
1.  Final Regression test
We have assigned 1804 text executions to about 20 volunteers, and completed
about 68% in execution (1221 test executions done). We are closing this
test window this week

Sub TotalAssignedNot Assigned
SubTotalRunNot Run
Mac66446136695203
Win75254423529083
Redhat5145141283860
Ubuntu37537537500
Debian12120120
Total209018041221583286

2. Release candidate acceptance test - test plan is ready, wait for RC
build, test guidance here:
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+RC+Acceptance+Test+Guidance

*Defect summary:*
1. Defect verification(with flag 4.0.0_release_blocker+) : there are 59
bugs in backlog now, among of them, 31 are for translation, 11 are for
code, which need actions from native reporters and development, respectively

Accomplished this week (only for Function UI)

Verified/FixedReopendWait for buildLook for env/platformNew
fixed/added in backlog
182548

Backlog at end of this week

TotalL10NFunction CodeFunction UI
59311117

*Issues & quality highlight:*
1. We need to clean up 59 resolved/fixed release blocker defects, there is
gap on translation defects' verification
2. Some of these defects were late changes, and we may have to wait for RC
to verify some of them
*
Volunteer status: *
1. No volunteers are for left translation defects' verification
2. No new volunteers(total 20 so far) on test execution work
3. 2 volunteers are on defect verification work, make little progress
*
Plan for next week:*
1. Work with volunteers to verify defects as release blocker (total 59)
2. Continue to do Drawing exploration test on Mac and Linux
3. Start to do RC acceptance test providing RC build is ready

Thanks you all for effort this week, we are towards to the release
candidate of AOO 4.0, let's continue and make progress next week!

Regards,
Yu Zhen

Re: Blog down?

[janI]

On 12 July 2013 08:47, Andrea Pescetti  wrote:

> On 10/07/2013 18:09, Rob Weir wrote:
>
>> I think we should plan on announcing the AOO 4.0 release availability
>> via a website page rather than a blog post.  We had issues with the
>> 3.4 and 3.4.1 releases as well, where the load from the announcement
>> (including press articles pointing to the blog post) brought the
>> server down.   A static web page will be better able to handle the
>> load.
>>
>
> I agreee. We should make two posts with identical content (static page on
> openoffice.org and blog post) and advertise the static version.
>
+1 I agree to that.

Blog is problaly going to be a longer problem, and will not hold up to a
big load even if it works.

fyi. There are considerations at the moment to replace roller to something
more modern (that was my wording).

rgds
jan I.


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

4.0.0_release_blocker canceled: [Bug 121823] update serf to new version 1.2.1

[bugzilla]

Ariel Constenla-Haile  has canceled  4.0.0_release_blocker:
Bug 121823: update serf to new version 1.2.1
https://issues.apache.org/ooo/show_bug.cgi?id=121823


--- Additional Comments from Ariel Constenla-Haile 
(In reply to h...@apache.org from comment #17)
> It already got in but the issue status wasn't updated.

blame it on the SVN Robot that forgot to remind me to do so.

@jsc: release blocker flag has no sense on this bug, it will appear in the Bug
List:"4.0.0_release_blocker+, Resolved", "normal" QA volunteer will have no
idea how to verify this.

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

Re: Building From Eclipse

[Andre Fischer]

On 12.07.2013 10:54, Ajay Bhat wrote:

Hi,

I'm using the Eclipse IDE for development and I've svn checked out the
OpenOffice trunk files. Can anyone give me a quick guide or point me to a
link to building in Eclipse as its not mentioned here
http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO?


I think that at the moment nobody know how that works or if it works at all.
However, I remember having seen a blog post by about building mozilla 
with eclipse.  It involved a lot of tweaking of eclipse's parameters 
like enlarging the amount of memory to the JVM and fiddling with CDT's 
parameters for scanning C++ files.  I will try to find the link but that 
may take some days.


The general steps would be:

- Create a new (C++) project from the SVN repository.

- Let eclipse download the source code.

- Let CDT scan all C/C++ source files.

- Wrap AOO's build command into an Ant file.

- Hit the button to build AOO


I guess that wrapping the build command into an Ant file is the hardest 
part.



-Andre



Thanks,

Ajay




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

Re: [VOTE]: Release OpenOffice 4.0 (RC)

[Sylvain DENIS]

+1

Sylvain DENIS
Expert TIC, WEB & FLOSS

Le 12/07/13 11:11, Jürgen Schmidt a écrit :

Hi all,

this is a call for vote on releasing the following release candidate as
Apache OpenOffice 4.0. This will be an important release for Apache
OpenOffice with bigger visible UI changes. It is a key milestone to
continue the success of OpenOffice.

This release candidate provides the following important changes compared
to former OpenOffice releases:

(1) a major UI change/improvement by introducing a new sidebar concept
where the idea is the comes from IBM's Symphony. It's the combination of
reimplementing a complete new framework for sidebars and merging the
existing sidebar in impress and code of various content panels from the
Symphony grant in OpenOffice.

(2) 190 fixes from Symphony are merged and integrated, mainly
interoperability issues

(3) 600 defects are fixed

(4) many more features and improvements are integrated

For a detailed feature overview please see the release notes under
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes.
But keep in mind that the release notes are not yet final and will be
updated and polished ...

The release candidate artifacts (source release, as well as binary
releases for 23 languages) and further information how to verify and
review Apache OpenOffice 4.0 can be found on the following wiki page:

https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshot

The related RAT scan for this RC can be found under
http://people.apache.org/~jsc/aoo-4.0.0_rat/aoo-4.0.0_rat-output.html

The RC is based on the release branch AOO400, revision 1502185!

Please vote on releasing this package as Apache OpenOffice 4.0.

The vote starts now and will be open until:

UTC at noon on Monday, 15 July: 2013-07-15 12:00 UTC.

But we invite all people to vote (non binding) on this RC. We would like
to provide a release that is supported by the majority of our project
members.

[ ] +1 Release this package as Apache OpenOffice 4.0
[ ]  0 Don't care
[ ] -1 Do not release this package because...

-
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

[VOTE]: Release OpenOffice 4.0 (RC)

[Jürgen Schmidt]

Hi all,

this is a call for vote on releasing the following release candidate as
Apache OpenOffice 4.0. This will be an important release for Apache
OpenOffice with bigger visible UI changes. It is a key milestone to
continue the success of OpenOffice.

This release candidate provides the following important changes compared
to former OpenOffice releases:

(1) a major UI change/improvement by introducing a new sidebar concept
where the idea is the comes from IBM's Symphony. It's the combination of
reimplementing a complete new framework for sidebars and merging the
existing sidebar in impress and code of various content panels from the
Symphony grant in OpenOffice.

(2) 190 fixes from Symphony are merged and integrated, mainly
interoperability issues

(3) 600 defects are fixed

(4) many more features and improvements are integrated

For a detailed feature overview please see the release notes under
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes.
But keep in mind that the release notes are not yet final and will be
updated and polished ...

The release candidate artifacts (source release, as well as binary
releases for 23 languages) and further information how to verify and
review Apache OpenOffice 4.0 can be found on the following wiki page:

https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshot

The related RAT scan for this RC can be found under
http://people.apache.org/~jsc/aoo-4.0.0_rat/aoo-4.0.0_rat-output.html

The RC is based on the release branch AOO400, revision 1502185!

Please vote on releasing this package as Apache OpenOffice 4.0.

The vote starts now and will be open until:

   UTC at noon on Monday, 15 July: 2013-07-15 12:00 UTC.

But we invite all people to vote (non binding) on this RC. We would like
to provide a release that is supported by the majority of our project
members.

   [ ] +1 Release this package as Apache OpenOffice 4.0
   [ ]  0 Don't care
   [ ] -1 Do not release this package because...

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

4.0.0_release_blocker requested: [Bug 122709] Change default size of application windows on Linux

[bugzilla]

j...@apache.org has asked  for 4.0.0_release_blocker:
Bug 122709: Change default size of application windows on Linux
https://issues.apache.org/ooo/show_bug.cgi?id=122709


--- Additional Comments from j...@apache.org
yes, I changed it back to ?

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

Building From Eclipse

[Ajay Bhat]

Hi,

I'm using the Eclipse IDE for development and I've svn checked out the
OpenOffice trunk files. Can anyone give me a quick guide or point me to a
link to building in Eclipse as its not mentioned here
http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO?

Thanks,

Ajay

[RELEASE]: OpenOffice 4.0 RC availability

[Jürgen Schmidt]

Hi,

the preparation of an OepnOffice 4.0 RC is nearly finished and the
upload is currently ongoing.

Mac and Windows are already available and the source release as well.
Linux upload is also ongoing but not yet finished.

Nevertheless the wiki page includes already links for the Linux
packages. If you have problem with a Linux download please check again
later.

Please find the RC builds under
https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshot

I will start the vote today and in parallel to the ongoing verification
and testing. If we don't find really serious showstoppers I will
continue with the release plan for next week.

Minor translation updates can we integrate in a potential language update.

Juergen

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

Re: 4.0 Release Dashboard

[Andrea Pescetti]

Jürgen Schmidt wrote:

I am still asking why we need the sub directories under binaries? We
have the file unique already and the language code is part of the file
name. The SDK name is also unique.


They are still handy in case a user wants to browse all available 
versions for a given language. It's still convenient to do so at times, 
so I would keep this.


Regards,
  Andrea.

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