You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Jürgen Schmidt <jo...@googlemail.com> on 2012/08/08 18:56:22 UTC
[RELEASE][3.4.1]: current status update
Hi,
I would like to give a short update where we are and what I would like
to propose.
We had investigated in
https://issues.apache.org/ooo/show_bug.cgi?id=120476 - Inserting a slide
in presentation will freeze AOO with clean environment.
It seemed to be a threading issue in this special scenario where many
things have influence. Bundled extension are using a separate new uno
process the first time the office is started and until the office gets
restarted. We found a fix to prevent the deadlock but the risk is high
to break something else and we looked for an alternative fix.
We analyzed pre-registered (prereg) extension and tried to prereg the
minimizer and the presenter screen. This worked quite well so far but it
means that both extension are not longer visible in the extension
manager. This is the designed and expected behaviour for prereg
extensions because some "clever" people thought that these extension are
part of the office and can be seen as by default supported features.
I would like to suggest that we integrate the minimizer and presenter
screen extensions as prereg extensions in AOO 3.4.1. We probably all
agree that both extensions provide useful features that should be
available by default.
For the future we can think of an integration in the core and drop the
extensions completely to reduce the complexity. But this can be defined
later.
We do currently some further tests ...
Juergen
Re: [RELEASE][3.4.1]: current status update
Posted by Kay Schenk <ka...@gmail.com>.
On Fri, Aug 10, 2012 at 1:01 AM, Jürgen Schmidt
<jo...@googlemail.com>wrote:
> On 8/9/12 4:39 PM, Ariel Constenla-Haile wrote:
> > Hi Jürgen,
> >
> > On Thu, Aug 09, 2012 at 01:33:29PM +0200, Jürgen Schmidt wrote:
> >> I would like to propose now a new snapshot build based revision
> >> 1371068 (tel:1371068).
> >
> > -1
> >
> > Didn't the last build show us that it is really a bad idea to propose
> > one build just because there is a fix for a release blocker? Browse the
> > archive looking for the rev. number to get a timeline idea:
> >
> > 1367440
> > 1367911
> > 1368799
> > 1368968
> > 1369110
> > 1369843
> >
> > A small resume: Rob's finding the missing update setting, Josef finding
> > two issues on Sunday, even before the RC was announced on Monday; a new
> > RC for those two fixes on Tuesday; now there is a fix, so yet another
> > RC... What if another release blockers are found tomorrow? Yet another
> > RC on Friday if the fix is available?
>
> First of all I already mentioned that I would change some things when I
> again would act as release manager. I would indeed expand the timeframes
> between more official snapshot builds. But not only this.
>
> We did official snapshots over some weeks and it seems that these
> snapshot were not tested very well. Some of the issue were there and
> were already in 3.4.
>
> Some of the issues were of course introduced by other fixes that were
> not tested careful enough. But that happened and everybody can try to
> improve the own work to reduce such things. But more important is that
> we improve the communication and coordinate the testing efforts better.
>
> I was also not very happy this time and I already mentioned that I
> wanted too much. But we agreed more or less on a release date end of
> July. And it looked not bad, all critical and marked blocker issues were
> fixed. And I simply tried to bring the release out, failed and learned
> my lesson ;-)
>
Juergen --
In my opinion, you are doing a great job as release manager. And yes, you
are correct that some of these misfires were caused by inadequate testing
of preliminary 3.4.1 releases starting from at least a month ago. As we
went along and I looked at the weekly reports that were supplied by QA, I
didn't feel the fixes warranted an additional download, and so I did
nothing. Maybe others felt the same, and we didn't do enough testing.
Consequently, some issues were evident until very late -- a week or so ago.
I appreciate your perspectives on all of this. We do need to put more
effort into diligent testing AND communication.
> Some of the issues who resulted in a new snapshot had nothing to do with
> the office but more with pro-active actions towards graduation.
>
>
> >
> > In the meantime, I propose
> >
> > https://issues.apache.org/ooo/show_bug.cgi?id=120518
> > https://issues.apache.org/ooo/show_bug.cgi?id=120389
> >
> > Crash bug 120389 has been reported on 2012-07-27, nobody notice it until
> > the user made some noise. This shows that something is really not
> > working with the way RC are proposed right after a fix is found for
> > a release blocker, IMHO there should be enough time (a week, for
> > example) to test the RC, even if a release blocker is detected, because
> > nothing prevent this from finding another release blocker.
> >
>
> I wouldn't have requested a new build when I would have seen this issues
> before.
> The bad things here is that we haven't noticed this critical issue for
> 10 days which is of course not good. But everybody who noticed such
> things can raise the fingers and can point others to such things.
>
> We should now really focus to fix the problems and bring 3.4.1 on the
> road as soon as possible.
>
> After the release is in front of the next release and we can reflect
> what went wrong or not so good and what can we improve and how.
>
> One thing is very clear we need working build bots. To reduce the
> workload for those who do the builds and make it more independent from
> single persons. And to provide regular builds for continuous testing and
> verifying.
>
> Juergen
>
>
>
>
>
>
>
--
----------------------------------------------------------------------------------------
MzK
"Never express yourself more clearly than you are able to think."
--
Niels Bohr
Re: [RELEASE][3.4.1]: current status update
Posted by Andrew Rist <an...@oracle.com>.
On 8/10/2012 1:01 AM, Jürgen Schmidt wrote:
> <snip>
> One thing is very clear we need working build bots. To reduce the
> workload for those who do the builds and make it more independent from
> single persons. And to provide regular builds for continuous testing
> and verifying. Juergen
The buildbots indeed need a bit of attention. We also need to expand to
have more diverse builds (3.4.1, in addition to trunk, for instance)
I will look at this this week (been off the grid - but I'm back now)
I will need some help - esp. with the Windows buildbot. Watch for
follow on messages with updated subject line.
A.
Re: [RELEASE][3.4.1]: current status update
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 8/9/12 4:39 PM, Ariel Constenla-Haile wrote:
> Hi Jürgen,
>
> On Thu, Aug 09, 2012 at 01:33:29PM +0200, Jürgen Schmidt wrote:
>> I would like to propose now a new snapshot build based revision
>> 1371068 (tel:1371068).
>
> -1
>
> Didn't the last build show us that it is really a bad idea to propose
> one build just because there is a fix for a release blocker? Browse the
> archive looking for the rev. number to get a timeline idea:
>
> 1367440
> 1367911
> 1368799
> 1368968
> 1369110
> 1369843
>
> A small resume: Rob's finding the missing update setting, Josef finding
> two issues on Sunday, even before the RC was announced on Monday; a new
> RC for those two fixes on Tuesday; now there is a fix, so yet another
> RC... What if another release blockers are found tomorrow? Yet another
> RC on Friday if the fix is available?
First of all I already mentioned that I would change some things when I
again would act as release manager. I would indeed expand the timeframes
between more official snapshot builds. But not only this.
We did official snapshots over some weeks and it seems that these
snapshot were not tested very well. Some of the issue were there and
were already in 3.4.
Some of the issues were of course introduced by other fixes that were
not tested careful enough. But that happened and everybody can try to
improve the own work to reduce such things. But more important is that
we improve the communication and coordinate the testing efforts better.
I was also not very happy this time and I already mentioned that I
wanted too much. But we agreed more or less on a release date end of
July. And it looked not bad, all critical and marked blocker issues were
fixed. And I simply tried to bring the release out, failed and learned
my lesson ;-)
Some of the issues who resulted in a new snapshot had nothing to do with
the office but more with pro-active actions towards graduation.
>
> In the meantime, I propose
>
> https://issues.apache.org/ooo/show_bug.cgi?id=120518
> https://issues.apache.org/ooo/show_bug.cgi?id=120389
>
> Crash bug 120389 has been reported on 2012-07-27, nobody notice it until
> the user made some noise. This shows that something is really not
> working with the way RC are proposed right after a fix is found for
> a release blocker, IMHO there should be enough time (a week, for
> example) to test the RC, even if a release blocker is detected, because
> nothing prevent this from finding another release blocker.
>
I wouldn't have requested a new build when I would have seen this issues
before.
The bad things here is that we haven't noticed this critical issue for
10 days which is of course not good. But everybody who noticed such
things can raise the fingers and can point others to such things.
We should now really focus to fix the problems and bring 3.4.1 on the
road as soon as possible.
After the release is in front of the next release and we can reflect
what went wrong or not so good and what can we improve and how.
One thing is very clear we need working build bots. To reduce the
workload for those who do the builds and make it more independent from
single persons. And to provide regular builds for continuous testing and
verifying.
Juergen
Re: [RELEASE][3.4.1]: current status update
Posted by Andrea Pescetti <pe...@apache.org>.
Rob Weir wrote:
> On Thu, Aug 9, 2012 at 12:16 PM, Ariel Constenla-Haile
> wrote:
>> Please don't mix frequent building on regular basis with what has been
>> happening here the last weeks. There have been two, three, RC build
>> proposal in the same week. The most notorious is the build announced on
>> Monday and the re build on the next day. IMHO this is mainly not fair
>> for volunteers doing QA work. ...
> It should be possible to do this:
> 1) Take the first RC of the series and stick with it for a week or
> more. Test it as completely as you want. So long as a test is not
> blocked, you can report all bugs against that RC.
Of course this works, but I can understand Ariel's concerns since it's
hard, for those not following development closely, to identify builds
(RC1, RC2 and RC3 tend to be better names than r1369843 and such) and
understand which one comes first, and why a given version is available
for certain operating system and not for others (since we don't publish
all build simultaneously).
> I agree that it would be difficult for a tester to take every RC and
> interrupt their work to install and restart testing on it.
Tests like those in (Italian, but the English version is quite similar)
http://wiki.services.openoffice.org/wiki/QA/TestCases//it#Test_Generale_su_AOO_3.4.1
tend to take one hour or so for each tester, so it's unlikely that
someone sees their work interrupted.
But still, a more regular cycle (like publishing a Release Candidate per
week and having a kind of schedule for uploading builds and receiving
feedback) would allow smoother operations. This will become easier when
the project graduates: at that point we will only need one vote and 3
days, as opposed to 2 votes and 6 days like now.
Regards,
Andrea.
Re: [RELEASE][3.4.1]: current status update
Posted by Rob Weir <ro...@apache.org>.
On Thu, Aug 9, 2012 at 12:16 PM, Ariel Constenla-Haile
<ar...@apache.org> wrote:
> On Thu, Aug 09, 2012 at 11:25:38AM -0400, Rob Weir wrote:
<snip>
>> But the existence or non-existence of a defect like this is
>> independent of the pace of builds. Frequent builds and frequent
>> testing is a good thing, IMHO. We just don't want that to translate
>> into frequent voting ;-)
>
> Please don't mix frequent building on regular basis with what has been
> happening here the last weeks. There have been two, three, RC build
> proposal in the same week. The most notorious is the build announced on
> Monday and the re build on the next day. IMHO this is mainly not fair
> for volunteers doing QA work. Of course, we have the former Symphony QA
> team being payed to work on AOO QA, nevertheless it was Josef (AFAIK
> he's not payed by IBM - correct6 me if I'm worng) who discovered the two
> issues on Sunday, at this last issues were detected by users (or thanks
> to user input, see https://issues.apache.org/ooo/show_bug.cgi?id=120517
> for the mozilla browser plugin).
>
I'd like to understand your concerns better. In what way is this "not
fair for volunteers doing QA work"?
I hope volunteers don't think that they need to repeat all of their
tests with every build. The IBM QA engineers certainly don't do a
complete test pass for every build.
It should be possible to do this:
1) Take the first RC of the series and stick with it for a week or
more. Test it as completely as you want. So long as a test is not
blocked, you can report all bugs against that RC. Of course, if
printing crashes, then printing is blocked.
2) The critical bugs that are found are then fixed. This could be
done in a single new RC or in multiple RC's. How that is done should
not impact the volunteer testers too much. They can ignore the
intermediate RC's if they want and continue testing on the first one.
Again, this assumes that testing is not blocked in a given area.
3) Additional RC's are useful because they unblock tests that are
blocked because of bugs.
4) When all critical bugs are fixed then we can do a "light" testing
pass on the final RC, concentrating on areas that were changed in the
final bug fixes.
I agree that it would be difficult for a tester to take every RC and
interrupt their work to install and restart testing on it. But I
don't think this is necessary. I'd only reinstall if it fixes a bug
that was of interest to me, or if it unblocks my testing.
-Rob
>
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
Re: [RELEASE][3.4.1]: current status update
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Thu, Aug 09, 2012 at 11:25:38AM -0400, Rob Weir wrote:
> > On Thu, Aug 09, 2012 at 01:33:29PM +0200, Jürgen Schmidt wrote:
> >> I would like to propose now a new snapshot build based revision
> >> 1371068 (tel:1371068).
> >
> > -1
> >
> > Didn't the last build show us that it is really a bad idea to propose
> > one build just because there is a fix for a release blocker? Browse the
> > archive looking for the rev. number to get a timeline idea:
> >
> > 1367440
> > 1367911
> > 1368799
> > 1368968
> > 1369110
> > 1369843
> >
> > A small resume: Rob's finding the missing update setting, Josef finding
> > two issues on Sunday, even before the RC was announced on Monday; a new
> > RC for those two fixes on Tuesday; now there is a fix, so yet another
> > RC... What if another release blockers are found tomorrow? Yet another
> > RC on Friday if the fix is available?
> >
>
> If the newly found bugs were caused by fixes to previous release
> blocker bugs, then that would be a big problem. But is this the case
> here? Recent bugs we've had are:
>
> -- password protection not working
this wasn't introduced by a bug in its previous RC, it could have been
detected in the nightly build from trunk, if the build boots were
actually working (that's not the case) and someone did QA on them (or
there where automated test performed on the build boot).
> -- update notifications not set
this comes from 3.4.0
> -- hang first time launching Impress due to threading issue with
> Presenter Console
this would have been detected in 3.4.0 if the extension wasn't broken,
but due to a bug it was installed but not working.
> I don't think any of these caused issues with printing. Certainly the
> browser plugin dialog issue goes back to March, before AOO 3.4.0.
I could reproduce the printing bug with 3.4.0 r1327774 and the latest
dev. build, so the bug was there from Oracle's beta.
> So we're finding new bugs. The frustrating thing is that we're not
> finding them sooner. For example, at least two of the bugs (the
> missing update notification setting and the the browser plugin dialog
> issue) existing in 3.4.0.
also the "printing" crash (actually, it's not a printing crash: it
crashed even if you cancel the printing dialog).
> It is certainly possible that waiting another week will uncover more
> such bugs. Waiting 2 weeks will find more. Waiting 2 months even
> more. But when do we know it is ready to ship?
>
> IMHO, there are two things we should be concerned with:
>
> 1) When a last minute fix is made, be sure that we're taking steps to
> reduce the risk of introducing new bugs. The risk is high because the
> last minute fix is made after the main test pass has completed. So
> you want to reduce the risk of new errors via code reviews, targeted
> testing, etc.
>
> 2) Ensuring that our main test pass for each release is able to
> complete before we vote on a release. Our confidence in the quality
> of a release relies on our test coverage.
>
> 3) Reducing unnecessary churn on those who are building the binaries.
Building these releases is something automated, it is likely imposible
that the build breaks at any point. Even uploading the binaries is
automated (at least me, I track if the upload is working fine from my
cell phone via ssh).
IMO the issue here is that the way the releases are been proposed is not
fair with the people doing QA (at least not with those volunteering, not
being paid by IBM ).
> > In the meantime, I propose
> >
> > https://issues.apache.org/ooo/show_bug.cgi?id=120518
>
> I don't see how that one is critical. What is the user impact? Is
> there data loss? A crash? Or is that dialog option just a no-op now?
the tab page in the Options dialog is offering a feature that has been
removed: there is no Mozilla plugin anymore. IMO it's like advertising
something to the user that she/he will never get.
Not a crash, but something not good.
> > https://issues.apache.org/ooo/show_bug.cgi?id=120389
[..]
> But the existence or non-existence of a defect like this is
> independent of the pace of builds. Frequent builds and frequent
> testing is a good thing, IMHO. We just don't want that to translate
> into frequent voting ;-)
Please don't mix frequent building on regular basis with what has been
happening here the last weeks. There have been two, three, RC build
proposal in the same week. The most notorious is the build announced on
Monday and the re build on the next day. IMHO this is mainly not fair
for volunteers doing QA work. Of course, we have the former Symphony QA
team being payed to work on AOO QA, nevertheless it was Josef (AFAIK
he's not payed by IBM - correct6 me if I'm worng) who discovered the two
issues on Sunday, at this last issues were detected by users (or thanks
to user input, see https://issues.apache.org/ooo/show_bug.cgi?id=120517
for the mozilla browser plugin).
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: [RELEASE][3.4.1]: current status update
Posted by Rob Weir <ro...@apache.org>.
On Thu, Aug 9, 2012 at 10:39 AM, Ariel Constenla-Haile
<ar...@apache.org> wrote:
> Hi Jürgen,
>
> On Thu, Aug 09, 2012 at 01:33:29PM +0200, Jürgen Schmidt wrote:
>> I would like to propose now a new snapshot build based revision
>> 1371068 (tel:1371068).
>
> -1
>
> Didn't the last build show us that it is really a bad idea to propose
> one build just because there is a fix for a release blocker? Browse the
> archive looking for the rev. number to get a timeline idea:
>
> 1367440
> 1367911
> 1368799
> 1368968
> 1369110
> 1369843
>
> A small resume: Rob's finding the missing update setting, Josef finding
> two issues on Sunday, even before the RC was announced on Monday; a new
> RC for those two fixes on Tuesday; now there is a fix, so yet another
> RC... What if another release blockers are found tomorrow? Yet another
> RC on Friday if the fix is available?
>
If the newly found bugs were caused by fixes to previous release
blocker bugs, then that would be a big problem. But is this the case
here? Recent bugs we've had are:
-- password protection not working
-- update notifications not set
-- hang first time launching Impress due to threading issue with
Presenter Console
I don't think any of these caused issues with printing. Certainly the
browser plugin dialog issue goes back to March, before AOO 3.4.0.
So we're finding new bugs. The frustrating thing is that we're not
finding them sooner. For example, at least two of the bugs (the
missing update notification setting and the the browser plugin dialog
issue) existing in 3.4.0.
It is certainly possible that waiting another week will uncover more
such bugs. Waiting 2 weeks will find more. Waiting 2 months even
more. But when do we know it is ready to ship?
IMHO, there are two things we should be concerned with:
1) When a last minute fix is made, be sure that we're taking steps to
reduce the risk of introducing new bugs. The risk is high because the
last minute fix is made after the main test pass has completed. So
you want to reduce the risk of new errors via code reviews, targeted
testing, etc.
2) Ensuring that our main test pass for each release is able to
complete before we vote on a release. Our confidence in the quality
of a release relies on our test coverage.
3) Reducing unnecessary churn on those who are building the binaries.
The process I'm familiar with aims to reduce the rate of code changes,
so less testing is invalidated by further code changes. It goes
something like this:
1. A "feature freeze" date. All new feature work for a release is
done. If a feature is not testable by that date it may be dropped from
the release plan. Bugs might still exist, but testing is not blocked.
2. This then allows a full test pass on the release, maybe a two-week
pass for a project like this. Bugs are still being fixed, and the QA
team will be sure to retest areas as they are fixed. But we rarely
have the luxury to do a 2nd complete test pass. So this requires
excellent communications between coders and testers.
3. After all critical bugs are fixed and verified you then have a
"code freeze". Any changes after this point must meet a high
threshold to be fixed. Further fixes might require code review, for
example. The goal is to avoid risk. Risk comes from code changes.
Any code change has risk. So we avoid even trivial fixes unless the
impact is severe. There are no risk-free trivial fixes.
So we're at step #3 now. The decision on whether to vote on the
release should be based on our confidence that there are no further
show stopper bugs. How do we know whether this is true? One formal
method is to look at bug find rates, e.g., the number of bugs you find
per hour of testing. As the product improves in quality this rate
will go down. There will always be more bugs to be found, of course,
but if the rate is coming down that is a healthy sign.
So doing another few days of testing is fine with me. But shouldn't
we be testing a new build with all the latest fixes in it?
> In the meantime, I propose
>
> https://issues.apache.org/ooo/show_bug.cgi?id=120518
I don't see how that one is critical. What is the user impact? Is
there data loss? A crash? Or is that dialog option just a no-op now?
> https://issues.apache.org/ooo/show_bug.cgi?id=120389
>
> Crash bug 120389 has been reported on 2012-07-27, nobody notice it until
> the user made some noise. This shows that something is really not
> working with the way RC are proposed right after a fix is found for
> a release blocker, IMHO there should be enough time (a week, for
> example) to test the RC, even if a release blocker is detected, because
> nothing prevent this from finding another release blocker.
>
Certainly the RC build did not create the bug. If this is a
regression and we're finding it this late, and from a user, it means a
few things:
1) the bug was introduced in error in a release that is supposed to
have only a handful of maintenance fixes
2) the bug was not detected in any previous formal test passes for this release
3) we're probably not paying enough attention to printing in our
testing in general, since we've seen two defects that would have been
obvious if printing was tested
4) we're getting useful feedback from users testing dev snapshots
outside of our formal testing work. But the reports are being missed,
perhaps because users are not aware of our conventions for setting
release blocker flags. There are several solutions here.
But the existence or non-existence of a defect like this is
independent of the pace of builds. Frequent builds and frequent
testing is a good thing, IMHO. We just don't want that to translate
into frequent voting ;-)
Regards,
-Rob
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
Re: [RELEASE][3.4.1]: current status update
Posted by Ariel Constenla-Haile <ar...@apache.org>.
Hi Jürgen,
On Thu, Aug 09, 2012 at 01:33:29PM +0200, Jürgen Schmidt wrote:
> I would like to propose now a new snapshot build based revision
> 1371068 (tel:1371068).
-1
Didn't the last build show us that it is really a bad idea to propose
one build just because there is a fix for a release blocker? Browse the
archive looking for the rev. number to get a timeline idea:
1367440
1367911
1368799
1368968
1369110
1369843
A small resume: Rob's finding the missing update setting, Josef finding
two issues on Sunday, even before the RC was announced on Monday; a new
RC for those two fixes on Tuesday; now there is a fix, so yet another
RC... What if another release blockers are found tomorrow? Yet another
RC on Friday if the fix is available?
In the meantime, I propose
https://issues.apache.org/ooo/show_bug.cgi?id=120518
https://issues.apache.org/ooo/show_bug.cgi?id=120389
Crash bug 120389 has been reported on 2012-07-27, nobody notice it until
the user made some noise. This shows that something is really not
working with the way RC are proposed right after a fix is found for
a release blocker, IMHO there should be enough time (a week, for
example) to test the RC, even if a release blocker is detected, because
nothing prevent this from finding another release blocker.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: [RELEASE][3.4.1]: current status update
Posted by Jürgen Schmidt <jo...@googlemail.com>.
Am Mittwoch, 8. August 2012 um 19:09 schrieb Rory O'Farrell:
> On Wed, 08 Aug 2012 18:56:22 +0200
> Jürgen Schmidt <jo...@googlemail.com> wrote:
>
> > Hi,
> >
> > I would like to give a short update where we are and what I would like
> > to propose.
> >
> > We had investigated in
> > https://issues.apache.org/ooo/show_bug.cgi?id=120476 - Inserting a slide
> > in presentation will freeze AOO with clean environment.
> >
> > It seemed to be a threading issue in this special scenario where many
> > things have influence. Bundled extension are using a separate new uno
> > process the first time the office is started and until the office gets
> > restarted. We found a fix to prevent the deadlock but the risk is high
> > to break something else and we looked for an alternative fix.
> >
> > We analyzed pre-registered (prereg) extension and tried to prereg the
> > minimizer and the presenter screen. This worked quite well so far but it
> > means that both extension are not longer visible in the extension
> > manager. This is the designed and expected behaviour for prereg
> > extensions because some "clever" people thought that these extension are
> > part of the office and can be seen as by default supported features.
> >
> > I would like to suggest that we integrate the minimizer and presenter
> > screen extensions as prereg extensions in AOO 3.4.1. We probably all
> > agree that both extensions provide useful features that should be
> > available by default.
> >
> > For the future we can think of an integration in the core and drop the
> > extensions completely to reduce the complexity. But this can be defined
> > later.
> >
> > We do currently some further tests ...
> >
> >
I would like to propose now a new snapshot build based revision 1371068 (tel:1371068).
I am traveling at the moment and will have limited network access over the weekend. We will have potentially a delay for Windows, MacOS and the src release. At least the signatures for Windows will be delayed.
But nevertheless I would like to ask to review and test this snapshot carefully. It becomes likely our next RC.
Juergen
> >
> >
>
>
> As a long term objective, it would be really useful to expand the minimizer so that it minimised Writer documents, targetted for a specific resolution output. Obviously this is not something that could happen overnight, but I suggest it as a worthwhile extension. Such a module might be shared between Writer and Impress, so might not add much bulk.
>
>
> --
> Rory O'Farrell <of...@iol.ie>
>
>
Re: [RELEASE][3.4.1]: current status update
Posted by Rory O'Farrell <of...@iol.ie>.
On Wed, 08 Aug 2012 18:56:22 +0200
Jürgen Schmidt <jo...@googlemail.com> wrote:
> Hi,
>
> I would like to give a short update where we are and what I would like
> to propose.
>
> We had investigated in
> https://issues.apache.org/ooo/show_bug.cgi?id=120476 - Inserting a slide
> in presentation will freeze AOO with clean environment.
>
> It seemed to be a threading issue in this special scenario where many
> things have influence. Bundled extension are using a separate new uno
> process the first time the office is started and until the office gets
> restarted. We found a fix to prevent the deadlock but the risk is high
> to break something else and we looked for an alternative fix.
>
> We analyzed pre-registered (prereg) extension and tried to prereg the
> minimizer and the presenter screen. This worked quite well so far but it
> means that both extension are not longer visible in the extension
> manager. This is the designed and expected behaviour for prereg
> extensions because some "clever" people thought that these extension are
> part of the office and can be seen as by default supported features.
>
> I would like to suggest that we integrate the minimizer and presenter
> screen extensions as prereg extensions in AOO 3.4.1. We probably all
> agree that both extensions provide useful features that should be
> available by default.
>
> For the future we can think of an integration in the core and drop the
> extensions completely to reduce the complexity. But this can be defined
> later.
>
> We do currently some further tests ...
>
> Juergen
As a long term objective, it would be really useful to expand the minimizer so that it minimised Writer documents, targetted for a specific resolution output. Obviously this is not something that could happen overnight, but I suggest it as a worthwhile extension. Such a module might be shared between Writer and Impress, so might not add much bulk.
--
Rory O'Farrell <of...@iol.ie>