State of the 0.7 release - planning adjustments needed
Simon Paquet
I must say that I'm a little bit worried at the moment. At the time of
writing this post, we still have
- 37 open blocker bugs
- 15 of those 37 bugs have no patch
- 14 of those 37 bugs have a patch, but the patch has not undergone any
kind of review yet
- 9 of those 37 bugs have no owner at all
- 8 bugs which have a patch, which has already undergone a first review
This is 20 days before our estimated release date for an RC1.
Given the fact that we need at least 2-3 days to let our builds
stabilize, move them through a QA-testday and prepare the release builds
in conjunction with the fact that at least some developers might want to
do some other stuff than coding and reviewing on a weekend, this only
leaves us 11-12 days to get this thing ready.
To make matters even worse, we have a string freeze coming up next Monday
and none of the 2 bugs with known l10n impact (392584 and 314339) have a
patch ready, which would allow us to commit the strings first before the
code itself is reviewed. And to add some more cream to the cake, one of
these bugs (314339 - foreign timezones) carries a high inherent risk with
it and should probably have gone into the tree weeks ago to test it
thoroughly.
I could even add some more stuff:
- we haven't started writing the release notes
- we haven't fixed the automatic inclusion of locales for Lightning issue
- we still haven't figured out the cause of the disappearing events
issues that many users are reporting
So what I propose is the following:
1. The blocker list has to go down fast. We won't manage that with our
current rate of fixing bugs. We need to re-triage the list to a
manageable. I consider this size to be 10-15 bugs at the most.
This will need a lot of tradeoffs to be made and will result in
pissing off some people. That is sad but the only real alternative is
pushing the RC1 release date back one month.
2. Someone needs to take care of the release notes. I will try to start
working on this in the next few days. I would appreciate any help I
can get on this (list of notable bug fixes for the what's new
section, updates on the state of the known issues, etc.)
3. Someone needs to tackle the disappearing events issue. This is
serious! It may hurt us big time in a software review. I don't want
0.7 to become our Netscape 6.0 release.
I would certainly appreciate your comments on this.
Simon
--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar
Michiel van Leeuwen
> That is sad but the only real alternative is
> pushing the RC1 release date back one month.
And how bad is that alternative? I consider it to be a good option...
Michiel
Simon Paquet
>> That is sad but the only real alternative is
>> pushing the RC1 release date back one month.
>
>And how bad is that alternative? I consider it to be a good option...
Sure, it is a viable option if it is decided that not enough bugs can be
cut from the release, because its quality would be degraded too much.
The aim of my post is foremost to be an eye-opener. In which direction
you look once your eyes are open is up to you :-)
Daniel Boelzle
> I must say that I'm a little bit worried at the moment. At the time of
> writing this post, we still have
>
> - 37 open blocker bugs
> - 15 of those 37 bugs have no patch
> - 14 of those 37 bugs have a patch, but the patch has not undergone any
> kind of review yet
> - 9 of those 37 bugs have no owner at all
> - 8 bugs which have a patch, which has already undergone a first review
>
> This is 20 days before our estimated release date for an RC1.
>
> Given the fact that we need at least 2-3 days to let our builds
> stabilize, move them through a QA-testday and prepare the release builds
> in conjunction with the fact that at least some developers might want to
> do some other stuff than coding and reviewing on a weekend, this only
> leaves us 11-12 days to get this thing ready.
We've gone thru the 0.7+ on the last status call and nobody really felt
worried. We still feel confident that we could do the majority of the
outstanding bugs, although we may miss some (especially the nobody ones).
> To make matters even worse, we have a string freeze coming up next Monday
> and none of the 2 bugs with known l10n impact (392584 and 314339) have a
> patch ready, which would allow us to commit the strings first before the
> code itself is reviewed. And to add some more cream to the cake, one of
> these bugs (314339 - foreign timezones) carries a high inherent risk with
> it and should probably have gone into the tree weeks ago to test it
> thoroughly.
- Berend takes care of doing the calendar menu cleanup and will check
the resources in before string freeze; the patch has already been reviewed.
- I slightly share your worry with the timezones thing; maybe Clint
could leave a statement here.
> I could even add some more stuff:
>
> - we haven't started writing the release notes
I'd appreciate if you could start that.
> - we haven't fixed the automatic inclusion of locales for Lightning issue
IMO nice to have, but not a blocker, causes only more manual work for
the release.
> - we still haven't figured out the cause of the disappearing events
> issues that many users are reporting
Needs to be investigated, thus is 0.7+.
> 1. The blocker list has to go down fast. We won't manage that with our
> current rate of fixing bugs. We need to re-triage the list to a
> manageable. I consider this size to be 10-15 bugs at the most.
> This will need a lot of tradeoffs to be made and will result in
> pissing off some people. That is sad but the only real alternative is
> pushing the RC1 release date back one month.
We already continuously retriage the blockers if necessary. After all, I
think the list is quite manageable since we have assignees for most of
the bugs, and about 3 weeks left for RC1. If somebody thinks he can't
follow the schedule with his blocker bugs, he should of course mention
that early.
> 2. Someone needs to take care of the release notes. I will try to start
> working on this in the next few days. I would appreciate any help I
> can get on this (list of notable bug fixes for the what's new
> section, updates on the state of the known issues, etc.)
great!
> 3. Someone needs to tackle the disappearing events issue. This is
> serious! It may hurt us big time in a software review. I don't want
> 0.7 to become our Netscape 6.0 release.
of course.
>
> I would certainly appreciate your comments on this.
>
> Simon
regards,
Daniel
--
Sun Microsystems GmbH Daniel Boelzle
Nagelsweg 55 Software Engineer
20097 Hamburg Phone: +49 40 23646 983
Germany Fax: +49 40 23646 550
http://www.sun.com/ mailto:daniel....@sun.com
Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering
Daniel Boelzle
> And on the seventh day Michiel van Leeuwen spoke:
>
>>> That is sad but the only real alternative is
>>> pushing the RC1 release date back one month.
>> And how bad is that alternative? I consider it to be a good option...
>
> Sure, it is a viable option if it is decided that not enough bugs can be
> cut from the release, because its quality would be degraded too much.
>
> The aim of my post is foremost to be an eye-opener. In which direction
> you look once your eyes are open is up to you :-)
IMO my eyes are open. I am working with our nightlies every day in my
productive environment and don't think we degrade in quality too bad.