View source for Planning Council/Galileo postmortem

= Galileo Planning Council postmortem =

''These notes were collected at the end of the Galileo Release, 6/17/2009, specifically just to collect them. And not to solve them, or even suggest solutions, but just to capture issues (good and bad) while the release was still fresh on our minds. Where solutions are suggested below, it was just to better capture the issue discussed .. not really to propose a solution. Action plans and solutions will be discussed in the Fall.''

== History ==

Galileo is the fourth simultaneous release, following Callisto, Europa, and Ganymede. The
Planning Council met regularly, starting in August 2008, firming up much planning at the
face-face meeting in October, 2008, at EclipseWorld. For meeting minutes, see
http://wiki.eclipse.org/Planning_Council.

The number of "must do" requirements was increased from previous years, with an explicit
desire to "raise the bar" and have projects reach a (slightly) higher level of quality than
in the past. The focus remained, as in previous years, on the 'simultaneous' part of
Simultaneous Release (as opposed to, say, a "one huge product" emphasis).

The original Galileo-PC Chair (Richard Gronbech) "retired" in January 2009 (due to change in
membership at Eclipse) [thanks for getting us off to a good start, Rich!] and a new chair
(David Williams) was named in March.

Our first delivered Simultaneous milestone was M6 (previous years were M5 or M4). 

== Comments from PC during 6/17 meeting ==

In general, PC members thought it went "ok", accomplished what was intended. 

The predictable date is great. 

The common P2 repository is good, and very important (such as for EPP, and others). Allows a
common place to get code that at least is roughly "correct" (in that the versions match up,
the jars are retrievable, etc) as compared to what it would be like going to 33 different URLs
to get the code that would be needed.

=== Quantities ===

And, we did increase the number of projects participating, to 33 (or so). The quantity was
seen as important, and a positive aspect (best for Eclipse and adopters) ... as long as
quality is reasonable, and it is understandable by consumers.

One issue related to "quantity" was the inconsistent nature of Project level. Some, such as
DTP, WTP, release and are tracked as one Top Level Project (even though each made up of a
number of sub-projects). Others, such as Modeling projects not only had sub- projects, but
also sub-sub-projects. It was noted that even then, while there were 33 "projects" tracked for
Galileo, there were 50 "projects" from the Foundation's records and IP Logs. So at least
consistency could be improved, if not perhaps even have an explicit "roll up" to top-level
projects.

Another issue related to quantity: consistency with things like the type and location of New
and Noteworthy would be good.

Automated tests are good (e.g. to check version numbers, about files) especially if earlier than this time and those test should be "rolled out" to Projects to run during their own builds!

=== Communication ===

Many noted that communication with projects (Project Leads) needed to be improved. 

: One idea was to have large group meetings. 

: Another was encourage PMC reps to communicate more with their Project Leads they are representing.

: Another was to perhaps meet "with everyone" once per milestone. 

Some specific communication issues: 

: 'Capabilities' requirements were not communicated well, and could improve their "delivery". 

: Late breaking requirement for Projects to update their meta-data to signify participation was not communicated to each PL.

=== Quality and Purpose ===

The nature of "must do" was questioned. Some voicing support that most really are "must do"
to use project code as a coordinated release (for example, signing doesn't help much unless
everyone does it), even "new and noteworthy" (not done by several projects) was probably not
communicated well that the goal is to "communicate with your users and get your early
testers motivated to do some early testing" .... and without some early testing, it's not
much of a release.

Some suggested presenting "must do" more along the lines of "good-for-you to do" (i.e. in a
project's best interests ... not an arbitrary rule "for everyone else").

Question raised about if "the release" and "update site" should be decoupled? Then projects
could be in common discovery site, even if not in simultaneous release. [In previous
meetings, we discussed and concluded "no" ... just documenting here what was discussed].

Keep emphasis on ability to meaningfully consumed (by end-users and adopters). 

Keep emphasis on "participation" by projects (and even increase that) (that is, attend
meetings, respond to notes, etc.)

Could "participation" be defined differently for different projects (for example, some might
want to be "date only", some meet some core requirements, but not all).

Perhaps projects could decide (in advance) in which capacity they would participate. And
then, "declare intent" early, so adopters know what to expect.

Discussion lead to the question of why do projects participate in the first
place? No one seemed to know :) so thought we should ask them. Some reasons that have been
heard in the past:

- they want mutual dates to allow easier consumption 

- coolness 

- right of passage (a recognized "real" Eclipse project then)

- learn a lot from the community of those releasing 

- publicity and visibility

[See Ian's BLOG on the 10 new projects for this release.]

=== Misc ===

Some wondered if we could improve the "delivery" of the code? 

- new front end to discovery site? Such as more "questions and answers" or wizard to narrow choices.

- should we still have EPP Packages.

- not to mention issues of zip files versus installable repositories.

Some would like longer-than-a-year maintenance. 

P2 is still not used by all adopters, being unpredictable and not understandable whereas
update manager works as expected (in same context). [Sort of unrelated to Simultaneous
Release ... but kind of is.]

== Notes after the meeting == 

One of the 'good' things about this cycle was improvements in the "aggregation" process; First with the builder created by Rich, which introduced the concept of modeling in the builds and build process (doh, why didn't we think of that before!) and then later with the Buckminster based builder which, among other things, worked around some P2 limitations to mirror sites much more quickly than otherwise possible, and added better 'integrity' checking and not, for example, accept bundles with incorrect checksums. Hopefully, many of these concepts can be carried forward into PDE and/or P2 directly, but we could not have done the Galileo release without these innovative approaches to dealing with thousands of plugins. 

A thought during final few days. There's really no process in place to "approve" changes at the last minute. It would be best to have an initial PMC Review, and then a request come from that PMC to Planning Council for final "vote" on respin or not respin.

During August Planning Council, John Arthorne provided some additional feedback (to paraphrase): The Eclipse Platform team did not participate in forming these notes, but that it corresponds to their own team-meeting notes, except they would have also added the "+1", "+2" categories of dependencies may be too simplified, since in reality, some projects need to deliver part of their components, say, at +0 or +1, but another leaf component at +2 or +3). They would also appreciate making sure that the simultaneous release criteria be better explained. 

See also [[Planning_Council/Galileo_postmortem_PLs]]

[[Category:Galileo]]