Update Lightning/Sunbird 0.3 Release schedule
Joey Minta
patches needed to be in by tomorrow, midnight. All of owners of these
bugs did a good job and every bug had a patch as of yesterday. However,
the amount of code simply makes it impossible to get all the reviews
done in time for these patches to land. Accordingly, we're revising the
0.3 release schedule as follows:
25 Aug. - Code slush begins. All high risk patches must have landed
before this.
2 Sept. - String Freeze. No changes to strings after this date.
6 Sept. - RC1
Additionally, in preparation for the Calendar Test Day on the 22nd,
there will be no high-risk landings allowed between midnight Sunday and
8am Tuesday. (All times Pacific.)
Keep up the good work everyone!
-Joey
dmo...@gmail.com
close. At this point, it looks like we should hit string freeze and
land all the high risk patches by this Thursday, September 7th. I
think we'll do well to wait until late Friday to make another estimate
about a date for a possible release candidate.
Dan
dmo...@gmail.com
Lightning string change momentarily. Furthermore, all the high-risk
bugs have now been landed.
Matt and I just spent a bunch of time triaging the 0.3 blockers, and
the list currently stands at 23 bugs, many of which already have
patches in hand.
We still need to triage the non-blocker dataloss bugs, of which there
are a fair number, and I suspect many of them are likely to be end up
being blockers. I'll post again on Monday after we've done that.
Dan
Jonathan Pritchard
Update on projected release? Are we looking at October now?
I'm not being pushy, just excited. You've done some really great work, guys.
--
Reclaim Your Inbox! http://www.mozilla.org/products/thunderbird
Peter Beattie
> I'll post again on Monday after we've done that.
Which Monday exactly were you talking about? ;>
--
Peter
Simon Paquet
> Matt and I just spent a bunch of time triaging the 0.3 blockers, and
> the list currently stands at 23 bugs, many of which already have
> patches in hand.
>
> We still need to triage the non-blocker dataloss bugs, of which there
> are a fair number, and I suspect many of them are likely to be end up
> being blockers. I'll post again on Monday after we've done that.
Right now, we're up to 26 open blocker bugs, 22 of which are
code-related. If we are serious about a release in September, this
number has to go down pretty fast (either by getting these bugs fixed
in the next 5-7 days or by re-triaging), because as experience has
shown from past releases, we need a full code freeze at least 7-10
days prior to release to shake out all regressions and for release
preparation (branching, l10n, website, amo, etc.).
Comments? Am I panicking?
--
Simon Paquet
Sunbird/Lightning/Calendar website maintainer
http://www.mozilla.org/projects/calendar
Dan Mosedale
Heh, indeed. Got a little bogged down in triage and other things. See
my upcoming reply to sipaq's post in this thread.
Dan
Dan Mosedale
> Right now, we're up to 26 open blocker bugs, 22 of which are
> code-related. If we are serious about a release in September, this
> number has to go down pretty fast (either by getting these bugs fixed
> in the next 5-7 days or by re-triaging),
Agreed. Matt checked in a bunch of fixes today, and with your help in
IRC this afternoon, we were able to cut a bunch more bugs in triage.
We now stand at 19 bugs blocking; several of those have patches in hand,
and I think several more should be utterly trivial to patch. If we're
lucky, we could get down to the low teens by tomorrow. We also have two
blocking? bugs that we need to consider, I suspect we'll get at least
one more tomorrow.
> because as experience has
> shown from past releases, we need a full code freeze at least 7-10
> days prior to release to shake out all regressions and for release
> preparation (branching, l10n, website, amo, etc.).
>
> Comments? Am I panicking?
No, I think you're right on the mark. I'd like to see us make September
still, but as you've pointed out, it's going to be close, and there's
only so much we can cut. I'm not quite willing to hazard a guess at
what date we'll hit a release candidate yet, because there are several
bugs on the blocker list that we don't really understand all that well.
Triage and analysis will continue, and, with luck and some
bullet-biting, we'll find more to cut.
Dan
Simon Paquet
>> Right now, we're up to 26 open blocker bugs, 22 of which are
>> code-related. If we are serious about a release in September, this
>> number has to go down pretty fast (either by getting these bugs
>> fixed in the next 5-7 days or by re-triaging),
>
> Agreed. Matt checked in a bunch of fixes today, and with your help
> in IRC this afternoon, we were able to cut a bunch more bugs in
> triage. We now stand at 19 bugs blocking; several of those have
> patches in hand, and I think several more should be utterly trivial
> to patch. If we're lucky, we could get down to the low teens by
> tomorrow. We also have two blocking? bugs that we need to consider,
> I suspect we'll get at least one more tomorrow.
At the moment we're up to 21 blocking bugs, which is the opposite
direction of where we should be going. I think it's time for some real
serious release management here instead of always pushing in just
another blocker and advocating everyone's pet bug to block the
release.
From the current list of release blockers only the following ones are
real user-visible blockers, which should be fixed immediately with a
release shortly thereafter:
- 346318 (Datepicker appears only briefly when clicking on date
dropdown)
- 348245 (Datepicker not working anymore after using date/year dropdown)
- 352842 (Bad import of UTF-8 ICS file with non-ASCII characters)
- 278236 (calDateTime.jsDate fails after 2037 and before 1970)
- 323171 (No logoff with FTP is done, a endless loop of messageboxes)
The last one could still be discussed, whether it's a real common user
operation or not. If it helps anybody, I will gladly take the blame for
the bad that comes out of not fixing the other bugs, that currently
block the release.
With the steps mentioned above, we could probably release an RC1 at the
end of the week, which would make a release in September a real
possibility.
Comments?
Cya
Simon
--
Clint Talbert
> Dan Mosedale wrote on 15. Sep 2006:
>
>>> Right now, we're up to 26 open blocker bugs, 22 of which are
>>> code-related. If we are serious about a release in September, this
>>> number has to go down pretty fast (either by getting these bugs fixed
>>> in the next 5-7 days or by re-triaging),
> At the moment we're up to 21 blocking bugs, which is the opposite
> direction of where we should be going. I think it's time for some real
> serious release management here instead of always pushing in just
> another blocker and advocating everyone's pet bug to block the
> release.
>
> With the steps mentioned above, we could probably release an RC1 at the
> end of the week, which would make a release in September a real
> possibility.
As the two posts above show, we're not moving as fast as we'd like
toward a release. In order to get some early QA (so that it doesn't
block the process further) could we get a pre-RC1, some nightly build
that has true branding turned on and has most of the blockers fixed.
Then while QA is working on testing that specific build, the remainder
of the blockers could be fixed, and we could release an RC2 or the real RC1.
Just an idea. Because I'd hate to wait until all the blockers are
addressed and then we land ourselves into some kind of find fix cycle
with QA. We will certainly continue to test nightly builds, but I can
bring a lot more attention to QA a pre-RC or an RC build than I can a
nightly. And we'd all probably want that attention sooner rather than later.
That's my two cents.
Clint
Dan Mosedale
>
> At the moment we're up to 21 blocking bugs, which is the opposite
> direction of where we should be going. I think it's time for some real
> serious release management here instead of always pushing in just
> another blocker and advocating everyone's pet bug to block the
> release.
So, thanks to your help with this in IRC yesterday, we're now down to 9
blockers.
> With the steps mentioned above, we could probably release an RC1 at the
> end of the week, which would make a release in September a real
> possibility.
I don't think we're terribly likely to make the end of the week, but I'm
not really ready to guess yet, as there are still a number of bugs that
we don't have a good handle on. I'll post an update here once it's more
clear.
Dan
Dan Mosedale
> As the two posts above show, we're not moving as fast as we'd like
> toward a release. In order to get some early QA (so that it doesn't
> block the process further) could we get a pre-RC1, some nightly build
> that has true branding turned on and has most of the blockers fixed.
> Then while QA is working on testing that specific build, the remainder
> of the blockers could be fixed, and we could release an RC2 or the real
> RC1.
I'd be pretty surprised if the branding makes much difference in the set
of bugs that we see. Would it be possible to just pick a reasonable
nightly and bless it? Or is the branding likely to make folks more
interested in doing QA on it?
Dan
Stefan Sitter
> I'd be pretty surprised if the branding makes much difference in the set
One reason is to test that official branding itself is working
properly on all platforms. (Remember Bug 351155 or Bug 352713 for
example)
/Stefan
Simon Paquet
>> With the steps mentioned above, we could probably release an RC1 at the
>> end of the week, which would make a release in September a real
>> possibility.
>
>I don't think we're terribly likely to make the end of the week, but I'm
>not really ready to guess yet, as there are still a number of bugs that
>we don't have a good handle on.
If we don't have a good handle on them, then it is very likely that those
bugs come with too high a risk to fix them so late in the game. Let me
quote schrep from his latest FF2 RC2 planning post over in
mozilla.dev.planning:
|We are in the end game here - which means days matter and our tolerance
|for risk is *zero*. We will not take bugs unless they are of great
|benefit: crashes, web compatibility, and major regressions. IMHO FF2
|RC1 is already a tremendously superior product to FF15. So let's wrap
|this up!
If you replace "FF2 RC1" with "current Sunbird/Lightning nightly build"
and "FF15" with "Lightning 0.1/Sunbird 0.3a2" this covers our current
story to a 100%.
I say it again, releasing is very hard, and it *always* means to make
hard decisions and to accept that you cannot fix every bug on planet
earth.
We are losing momentum here by letting our users needlessly wait for a
product that, with a 1-2 week stabilization period, will be far superior
to what they currently use and also by letting them download 5-6 month
old releases with a high number of serious bugs, which have all been
fixed right now and at last by not giving our Sunbird users a new final
release for over 18 months now.
Simon
--
Sunbird/Lightning/Calendar Website Maintainer:
http://www.mozilla.org/projects/calendar
Sunbird/Calendar blog: http://weblogs.mozillazine.org/calendar
dmo...@gmail.com
> And on the seventh day Dan Mosedale spoke:
>
> >> With the steps mentioned above, we could probably release an RC1 at the
> >> end of the week, which would make a release in September a real
> >> possibility.
> >
> >I don't think we're terribly likely to make the end of the week, but I'm
> >not really ready to guess yet, as there are still a number of bugs that
> >we don't have a good handle on.
>
> If we don't have a good handle on them, then it is very likely that those
> bugs come with too high a risk to fix them so late in the game.
Indeed, I think you're right. I cut the "foreign timezones" bug today
after much agonizing. We now have patches in hand for all the blockers
except the BYSETPOS bug, and unless one of us gets a bright idea of an
easy fix for this by early tomorrow, I suspect that will end up being
cut as well. This means that, if we're lucky and none of the current
patches regress terribly, we will have a release candidate this week.
I appreciate your continuing to push in the right direction of getting
0.3 out the door.
Dan