Unfortunately I won't be able to attend
the planning council call on July 7th. Here are some initial notes for
the retrospective discussion:
- First, I think the post-mortem is
a bit early. Last year we did this in August, and we haven't had a chance
to have all the necessary discussions within our own project to provide
good input yet. I hope we will also have some time in the August call for
further discussion on it.
- For planning purposes, it would be
useful to know the subsequent release name earlier. We only selected the
Indigo name a few weeks before the Helios release was out. I'm sure many
projects start thinking about their next release before June and it would
help to have a name associated with it. Perhaps we should even select the
next two or three release names all at once - both for continuity/consistency
of naming and avoid the annual churn of the name selection process (I vaguely
remember this being done before).
- Every release train milestone and
RC starting with M1 was delivered on time! This an amazing accomplishment
and the first time this has been on time for the entire release cycle as
far as I remember. Actually there was one exception: M2 was released a
- Having the +0,+1,+2,+3 dates on contiguous
days felt a bit tight. There was no room for build failures or last minute
problems. I.e., a project team has only 24 hours from when their prerequisites
are available until they must deliver their final bits for the milestone.
If they discover a problem caused by their prerequisite they have very
little time to diagnose and iterate with the upstream project. Having
said that, we did manage to ship on schedule every time so maybe it is
ok. One possible improvement would be to encourage projects to deliver
"candidate" builds to the staging repository before their milestone
release date, with the caveat that their bits could still change. That
would allow downstream projects to build/test against the candidate, and
report problems upstream before it is too late.
- If we are going to test and enforce
legal files in bundles (about.html, etc), we need to start doing it earlier.
It appears this was only tested *after* RC4 and it caused a last minute
firestorm for several projects (bug 316720). I know this is the responsibility
of each project, but if we have the tools available to run on the release
train repository we should try doing it earlier (say M7).
- There were a few cases of unexpected
contributions sneaking into the build unannounced after their due date.
I think we should have the flexibility to accomodate late changes but they
at least need to be communicated so anyone downstream can react. It would
be nice if we could avoid it, but maybe we need to "lock" the
build at the end of the +2 date and only rebuild if requested on the list
for all to see. I can give examples where this happened but it's nicer
to avoid naming names ;)
That's all for now. I may have more
to add after we've had a round of retrospectives within our projects.