REMINDER: Release 3.4.0-rc1 from ooo-build-3-2-1 branch == string and UI freeze

l10n
#1

Hi,

please note that today is commit deadline for LO-3.4.0-rc1 release. It
is also string and UI freeze.

Commit rules for libreoffice-3-4 branch after May 2, 2011:

  + do not modify strings or UI
        + commit only safe bug fixes
        + send notification about your commit to
          the libreoffice@lists.freedesktop.org mailing list [*]

For more deadlines see
http://wiki.documentfoundation.org/ReleasePlan#3.4.0_release

[*] The review before commits will be most likely needed after the
deadline for 3.4.0-rc2. The steering committee will decide about it on
Thursday. We want to be more relaxed this week to encourage people to
work on bugfixes.

Best Regards,
Petr

#2

Christian Lohmaier píše v Po 02. 05. 2011 v 14:04 +0200:

HI *,

>
> please note that today is commit deadline for LO-3.4.0-rc1 release. It
> is also string and UI freeze.

Before you release any version as RC, make sure the build can actually
be started.

Sure.

There has not been a response/solution to
http://lists.freedesktop.org/archives/libreoffice/2011-April/011243.html
/
https://bugs.freedesktop.org/show_bug.cgi?id=36275 yet.
yet

I can't believe that the bug have had low severity for so long. Thus it
was hidden amongst other bugs.

We are looking at it now.

Best Regards,
Petr

#3

HI *,

please note that today is commit deadline for LO-3.4.0-rc1 release. It
is also string and UI freeze.

Before you release any version as RC, make sure the build can actually
be started.

There has not been a response/solution to
http://lists.freedesktop.org/archives/libreoffice/2011-April/011243.html
/
https://bugs.freedesktop.org/show_bug.cgi?id=36275 yet.
yet

ciao
Christian

#4

Christian Lohmaier wrote:

Before you release any version as RC, make sure the build can actually
be started.

There has not been a response/solution to
http://lists.freedesktop.org/archives/libreoffice/2011-April/011243.html
/
https://bugs.freedesktop.org/show_bug.cgi?id=36275 yet.
yet

Petr mentions it'll be fixed for rc1, so I'd trust him there. :slight_smile:

Cheers,

-- Thorsten

#5

Hi all,

Christian Lohmaier wrote:

Before you release any version as RC, make sure the build can actually
be started.

There has not been a response/solution to
http://lists.freedesktop.org/archives/libreoffice/2011-April/011243.html
/
https://bugs.freedesktop.org/show_bug.cgi?id=36275 yet.
yet

Petr mentions it'll be fixed for rc1, so I'd trust him there. :slight_smile:

Yes I do too, but the issue is that we didn't test the betas at all yet due to this bug, and it covers a quiet large range of distributions.
So, may be we should really take time to test the RC fully before really calling it an RC and spread the word around it.

Kind regards
Sophie

#6

Sophie Gautier wrote (02-05-11 20:28)

Yes I do too, but the issue is that we didn't test the betas at all yet
due to this bug, and it covers a quiet large range of distributions.
So, may be we should really take time to test the RC fully before really
calling it an RC and spread the word around it.

Good suggestion Sophie!

Cor

#7

Hi Michael,

Yes I do too, but the issue is that we didn't test the betas at all yet
due to this bug

  Which sucks; hopefully the Windows& Mac builds have been use-able for
testing - and of course, the snapshots of them.

Not sure about Mac, but I think we have a lot of testers under Linux.

and it covers a quiet large range of distributions. So, may be we should
really take time to test the RC fully before really calling it an RC
and spread the word around it.

  The danger of this - is that by introducing further delay into the
release pipeline - we slow down our ability to respond to bugs that are
found, and since we are releasing a build per week anyway - we can only
really choose to miss out a week: which isn't that wonderful :slight_smile: Already
we only have a few days to fix a bug in RC<n> and get the fix out in
RC<n+1>.

  -Far- better for people to be running and using the daily snapshot
releases and reporting bugs against them - instead of waiting for RCs
(per-se).

Yes agreed, there is a lot of room for improvement on the testing side. But betas are supposed to be tested too :slight_smile:

  Having said that - warning that RC1 may be a bit rough in the release
notes is a good idea :slight_smile:

But a RC1 is supposed to be a release candidate, so how could it be rough? I mean I understand all the reasons you have given above about correction of bugs, etc. And I know we have a good part of responsibility for not pointing the stopper at the good time.
What I'm trying to highlight also here is the communication. It's quiet frustrating to not be able to install a version when you want to contribute to tests, and having a RC that is rough sound strange for me.

- although, given that this is caused by some

obscure compiler problem - apparently only present on the gross / old
system we compile the binaries on for Linux, I'm optimistic that once it
is fixed we'll not be in such terrible shape.

Ok, let see.

Kind regards
Sophie

#8

Hi Kendy,

Jan Holesovsky wrote (03-05-11 11:17)

Please - what went wrong that this serious bug has not appeared among
the 3.4 Most Annoying Bugs? Without that, it was impossible to focus on
this - it just stayed hidden among the flow of the other 'normal' bugs.

I guess it's partly my fault, cause I expected the problem to be picked up, cause it was mentioned on some lists long ago. A bit naive, but attracting in times of large work loads :slight_smile:

And please, do you have suggestions what can we do to stress / get to
the public knowledge that:

- to get the proper attention to the real blockers, they _must_ appear
in the Most Annoying Bugs
[https://bugs.freedesktop.org/show_bug.cgi?id=35673]

- the Most Annoying Bugs are meant for really serious bugs only, and not
for "my favorite red button should be blue", and that such bugs will be
removed from there

- daily builds [http://dev-builds.libreoffice.org/] are important, and
can be used for testing even between betas, ie. the next day after the
bug is fixed, and pushed to the repository

AFAIAC, I mention those regularly on the Dutch lists.
We need time to get this in the minds (and hearts) of the people.

Kind regards,
Cor

#9

Hi Michael,

Michael Meeks wrote (03-05-11 12:30)

Yes I do too, but the issue is that we didn't test the betas at all yet
due to this bug

  Which sucks; hopefully the Windows& Mac builds have been use-able for
testing - and of course, the snapshots of them.

But are we relative sure that this does that give enough feedback from people we can expect to help testing?

and it covers a quiet large range of distributions. So, may be we should
really take time to test the RC fully before really calling it an RC
and spread the word around it.

  The danger of this - is that by introducing further delay into the
release pipeline - we slow down our ability to respond to bugs that are

I don't see this problem. The current build scheme can be kept, just in the naming there will be a shift.

found, and since we are releasing a build per week anyway - we can only
really choose to miss out a week: which isn't that wonderful :slight_smile: Already
we only have a few days to fix a bug in RC<n> and get the fix out in
RC<n+1>.

  -Far- better for people to be running and using the daily snapshot
releases and reporting bugs against them - instead of waiting for RCs
(per-se).

Yes, but as mentioned before: people have to get used to this way of working.
Plus that still the snapshots (and betas) will replace the stable version, which does not help testing too.
So that are all pointers that we are risking quality.

  Having said that - warning that RC1 may be a bit rough in the release
notes is a good idea :slight_smile: - although, given that this is caused by some

I will have to advice people to be very careful with installing a RC1 that has been probably tested rather little and is to replace the stable version and also introduces a lot of changes in our code base.

obscure compiler problem - apparently only present on the gross / old
system we compile the binaries on for Linux, I'm optimistic that once it
is fixed we'll not be in such terrible shape.

I try to share your optimism, but would feel far more comfortable with an intermediate step looking at the very special situation.
Would it bring someone in big trouble?

Kind regards,
Cor

#10

Hi Alex,

The question will also arise when testing nightly/daily builds as
to which branch of the repo actually represents the build - my
understanding is that the nightly/daily is from master - this is not the
same as the feature/string frozen branch of a future release, even if
the changes/bug fixes are pushed back to master afterwards.

http://dev-builds.libreoffice.org/daily/Linux_x86_Release_Configuration/libreoffice-3-4/

http://dev-builds.libreoffice.org/daily/Linux_x86_64_Release_Configuration/libreoffice-3-4/

http://dev-builds.libreoffice.org/daily/MacOS/libreoffice-3-4/

Some of the tinderboxes cover master, but most important at this stage
is of course the release branch; these are builds of exactly the code
that is going to be tagged as betas / RCs.

Regards,
Kendy

#11

Hi Alex,

> Some of the tinderboxes cover master, but most important at this stage
> is of course the release branch; these are builds of exactly the code
> that is going to be tagged as betas / RCs.

Thanks for the links, I'd already noticed that they existed, but most of
the time, they didn't seem to be populated with anything. I see that the
last daily for which files are available for MacOSX was 28/04, even
though there were successful builds at later dates.

That's unfortunate :frowning: - Norbert, please, it seems something went wrong
with the MacOSX tinderbox, it does not upload any recent build, can you
check?

How is a tester to know what the correlation is between any build of a
given date and a beta or rc ?

According to the date/time of the tagging - when the date is eg.
something after the tagging of Beta3, but before Beta4, you have - well
- something in between Beta3 and Beta4. So far the tinderboxes do not
do automatic builds of exactly the tag when introduced, but I hope we'll
update them soon to be able to do such a thing.

How do I know whether stuff that fails on,
say the build of 28/04, has not been fixed by the later date builds, if
those aren't available for me to compare ?

So - in 99% of cases, the bugs do _not_ "go away by themselves". So if
you have a bugreport where the developer eg. says "it has been fixed and
pushed to libreoffice-3-4", just compare the date/time of such a message
and the date of the nightly build of the libreoffice-3-4 branch - before
that date, it is supposed to be broken, after that, it is supposed to be
fixed.

If there is no such a bug report, the probability the bug will be fixed
is quite low.

I'm just trying to understand
what it is we are actually supposed to be testing with regard to
Michael's comments that we use the nightly builds for QA. As you can
see, I am quite confused at the moment.

First of all - if the build starts / ends / loads / saves several
documents. If it does not, we have a serious problem, and the
probability is high that the same problem will be in the next beta / RC.
Please note that 'build does not start' belongs to the Most Annoying
Bugs, to have the proper attention.

Then of course you eg. want to test the new functionality, like from the
planned release notes:

http://wiki.documentfoundation.org/ReleaseNotes/3.4

Regards,
Kendy

#12

I won't be able to fix it until friday (on the road, and that machine
is _not_ accessible remotely)