August 23, 2005, Boston, Massachusetts
| Present | Regrets | ||
Paula Cox, IBM (visitor) |
Richard Gronback, Borland, GMF Kevin Haaland, IBM, Platform Wenfeng Li, Actuate, BIRT Tim Wagner, BEA, WTP |
John Duimovich, IBM |
|
(these notes are in logical rather than chronological order)
ACTION: Kevin H will come to the August Planning Council meeting with the mechanics of what projects are opting-in to; and at the August meeting the project will opt-in or not - completed, see below.
ACTION Bjorn FB will write some tools that process these XML status reports: collate them for the website; build the timeline of releases; send reminders to project leaders who have not updated their status; etc. - file format proposed; tools not written; re-promised for 4Q2005; see below.
ACTION Everyone agreed to freshen their content, either by (the best choice) making it good or (second choice) removing all the obsolete and incorrect pages. Everyone agreed to do so by one month after the Platform 3.1 release ships, if not before - a couple projects freshened their content, most did not; re-promised for end of September; see below.
We re-discussed how the Eclipse.org website has a lot of woefully out-of-date, and perhaps even wrong, pages lying around. We agreed that we need to have either good information or no information, but we cannot tolerate bad data.
ACTION: [ALL] Everyone agreed to freshen their content, either by (the best choice) making it good or (second choice) removing all the obsolete and incorrect pages. Everyone re-agreed to do so by the end of September, if not before.
At the first Committer Gathering (held in Portland), the committer community suggested that each project home page have "the same four links in the same place with the same names" so that anyone could go to a project page and find the essential project information. Everyone thought this was a good idea and we decided: (a) that the "four links" should be at the top of the left menu bar; (b) that there should be more than four links (see list below); (c) that they should be fly-out menus; and (d) that Bjorn should create some magical PHP include file that does this all in very easy, "takes no effort on the part of the projects", way.
There are three audiences for this material: consumers, contributors, and project members. It's hard to choose a set of links that is both useful and compact, but this is what we decided to try:
ACTION: [Bjorn FB] agreed to create the PHP include script for the menu and Tim W volunteered WTP to be the test project. Doug G volunteered to evaluate the instructions against the goal of "takes no effort on the part of the projects".
ACTION: [Bjorn FB] to create a blank template initial project website so that new projects don't have to browse around and copy others.
Kevin H described the Platform 3.2 schedule and discussed the modifications that will be necessary for the train. There was a lot of discussion around the train and what it will take to coordinate and release on the same date. The overall summary is that the end game will be extended by an additional milestone and thus API Freeze will be M5 and Feature Complete will be M6/RC0. (Note that the milestone dates in 2006 are in flux and will probably be adjusted to work around EclipseCon.) M2 is September 23rd, M3 is November 4th, and M4 is December 16th. Each project is assigned a "offset" number which is the number of weeks their milestone dates are offset from the Platform dates. Thus BIRT, being a +1 project, has milestone dates of M2 = Sep 30, M3 = Nov 11, M4 = Dec 23, etc. These offsets will (obviously) be reduced over the end-game (e.g. +1 week, +1 half-week, +1 quarter-week, +1 day, +1 hour, etc) until they all reach zero. These offsets are a loose characterization of their dependency on other projects - loose because the dependencies are grouped into three buckets (+0, +1, +2) rather than the five or six that a full dependency list would entail. Five buckets would not work for six week milestones, hence we collapsed it to three buckets.
The projects participating in the release train, the milestone they expect to start synchronizing, and the offset are as follows:
Note that participation in this initial train is limited - not everyone who wants to join will be able to join this year. Assuming success, the process will be opened to additional projects next year. Also note that if a project falls behind the train schedule, it will be dropped - we will not slip the train. A third note: any project that has not synchronized by M5 is off the train for this year.
What does it mean to be "on" or "off" the train? First, any project is welcome to release simultaneously with any other project. The existence of the release train does not prevent, e.g., Mylar, from releasing at the same time as the Platform. The difference is two-fold: first, the Foundation expects to have some press activities around the train release; projects that are part of the train will get more attention than projects that are not. Second, the projects on the train are committing to help each other achieve the release. Thus bugs submitted by train members will likely get more attention than bugs submitted by non-members.
ACTION: [Kevin H and Paula C] will pass this information along to the EMF, GEF, VE and UML2 leads. - Completed 9/11
ACTION: [Doug G or Bjorn FB] will pass this information along to the CDT leads.
ACTION: [Bjorn FB] will work with the Tools PMC and the Executive Director to get the right representation for EMF, GEF, VE, and CDT at the train coordination portion of the December and March Planning Council meetings.
ACTION: [Wenfeng L, John G, Tyler T, Tim W, John D] All train projects need to have a project plan.
ACTION: [Bjorn FB] at EclipseCon, the PC and Eclipse legal will meet to coordinate all the IP reviews and Release Reviews so that there isn't an impossible-to-complete mad rush at the end.
FYI The tentative Platform maintenance releases are 3.1.1 end of September and 3.1.2 end of January/February.
Bjorn FB brought forward a proposed project status reporting file format. Discussion included:
ACTION: [Bjorn FB] will update the proposal, publish it, and write the software to parse it.
We discussed the Roadmap process. Last year's Roadmap 1.0 was difficult to put together and we want the process to be easier this year. One question we had for the Council plenary is whether the timing is correct, i.e., should the Roadmap be done in July after the train release and thus be a 12 month planning document, or should we stay with January which makes it a 3 month and 15 month planning document? The project status reporting format (above) will have all the information necessary for the PC contributions to the Roadmap except for the Forward Looking Statement section. We plan to change that section to "Thematic Advancement" and describe how each project is contributing to the Themes and Priorities. In other words, to concrete statements about higher levels features and how they are being worked on. Be sure to refer to which release the feature is going into, especially for projects (like TPTP) that have multiple releases per year.
Then we switched to a discussion of how to make the Roadmap a more useful document for the projects. All projects stated that they were using the Themes and Priorities as part of their planning process, but only one part. The key thing that all requirements coming into a project need to have is compelling value to the project team. Requirements also need to be actionable, i.e., have attached Bugzilla entries. It is important to remember that at Eclipse, there is a meritocracy of ideas and thus requirements need to justify themselves.
Kevin H pointed out that we all believe that the integrity of the Eclipse brand means something. And this means that all projects have to spend some time working on requirements that are "for Eclipse" rather than just "for the project". Some projects are better at this than others, but all of them need to make sure they spending time on the greater good. (We also have to make sure that when we reject something (such as a Bugzilla WONTFIX), we do so with care because bad news travels quickly.)
ACTION: [Bjorn FB] will add these words to the guidelines
Wenfeng L brought a set of defect tracking requirements to the Council - difference between Acutate's internal bug tracking system and Bugzilla. Wenfeng entered these as bugs 106261 and 106263. After discussion, the bugs were updated with the Councils suggestion that many of the requests are already handled by Bugzilla, but that adding options for enhancements was a good idea.
Discussion of the newly visible, but has always existed, requirement that all projects keep a Project IP Log. The draft guidelines include a description of the log.
ACTION: [Bjorn FB] fix the grammar/spelling errors; fix the query explanation to include that Bugzilla needs to record the contributor's name; add that all patches must be submitted through Bugzilla, never by email;
ACTION: [Bjorn FB] discuss with Mike M and Janet C the Eclipse privacy policy versus the Project IP Log; note that if the IP log requires all contributor addresses to be public, that will violate our privacy policy
Tim W has entered bug 105636 asking for a better tracking scheme for IP forms and approval requests.
The Council as a whole requested that Bjorn work with Janet to clarify exactly what the process for code contributions is. For example, can the code be placed in Bugzilla so that it can be looked at? Can the code be used before the "ok to use" answer returns from Eclipse legal? Does the same full process apply to junior developers at the same company but who are not yet committers? There are many scenarios to consider and the Council members would like a step-by-step colored flowchart of the process to follow. For example, "green if you have authored all the code", "yellow path if authored by a junior member of your team and you work for a member company", etc.
In general the Council thought the Development Process Guidelines were good, but they felt that the guidelines should be improved in a number of areas:
The Council wants to have a good process, but they also want to make sure that we don't set the bar too high or we will never have new projects or new committers.
ACTION: [Bjorn FB] make these changes
The Council discussed project mentors. We decided to try a committer-to-committer mentoring program from the experienced (mature) projects to the less experienced (incubation) projects. The goal is to transfer knowledge of all those little things that make being a committer in an Eclipse project easier.
ACTION [Kevin H, Sri D, Tim W] each to provide the names of three mentors. These people will be paired with committers on DSDP, DTP, and GMF.
The Council is concerned that email addresses in Bugzilla are showing up on Google and can be viewed by people who don't even have an Eclipse Bugzilla account.
ACTION: [Bjorn FB] follow up with Denis on this issue
Notes taken and posted by Bjorn Freeman-Benson