Re: [eclipse.org-planning-council] Helios retrospective

[David M Williams <david_williams@xxxxxxxxxx>]

Thanks John ... if not clear ... we
can discuss "input", issues, and improvements at any time! ....
This particular meeting and schedule is to encourage everyone to note issues
while fresh on our minds.  But, no, not only opportunity. 

Our 7/7 meeting will be at 1 PM Eastern
 (from the votes, we'd get more attendees than we'd lose by shifting
one hour, from the original noon, to 1 PM). .... We'll also discuss if
this is a better permanent time? 

I've started an agenda at 
http://wiki.eclipse.org/Planning_Council/July_07_2010

From:	John Arthorne <John_Arthorne@xxxxxxxxxx>
To:	eclipse.org-planning-council@xxxxxxxxxxx
Date:	07/02/2010 02:27 PM
Subject:	[eclipse.org-planning-council] Helios retrospective
Sent by:	eclipse.org-planning-council-bounces@xxxxxxxxxxx

---

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 day early. 

- 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. 

John_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to
the Eclipse Foundation.  To be permanently removed from this list,
you must contact emo@xxxxxxxxxxx to request removal.