Planning Council Agenda

This page is where we can gather the agenda for the next Eclipse Planning Council face-to-face.

Location

The next face-to-face will be at EclipseWorld in Reston, VA. We will meet in afternoon of Tuesday November 6th at the conference hotel the Hyatt Regency Reston.

Agenda

This is the big kick-off planning meeting for Ganymede and it behooves all projects who plan to be part of Ganymede to attend this meeting.

For reference and context, please review the previous meeting minutes from June.

Europa Fall and Winter Maintenance

We need to be better coordinated. We almost seemed like two separate groups for this Fall release: one group that released Friday morning and another that was still conforming to the posted schedule for getting their bits in. See Nick's Europa#Coordinated_Maintenance proposals.

Nick suggests:

Europa  +0      +1      +2      EPP    Freeze   Release
Winter  02/18   02/20   02/25   02/27   02/28   02/29

Nick asks: given EclipseCON is Mar 17, we could delay M5 by a week or two and still be done in time. Good idea/bad idea?

Kim says: As for communication, there were many questions sent to the lists regarding the schedule. If the Europa status were sent out regularly and also noted the upcoming tasks required to hit the release dates, a lot of unnecessary email could have been avoided. Yes, it is available on the wiki but the reality is that everyone is busy and forgets to check it.

Kim says: Perhaps for Ganymede we could have a wiki page where we could all sign off on the builds. This is a low-cost solution to reduce confusion and the amount of email on the list. Bjorn says: perhaps even for the Europa Winter Maintenance?

Oisin says: We're a +2 project that has a dependency on a +2 project. This has caused issues in the past. I would like to see a +3 phase discussed.

Define the Ganymede Musts and Shoulds Rules

We will set the rules for what it means to be part of Ganymede: the should dos and the must dos. We (the EMO) will be enforcing the must dos this year.

Milestone Dates

We will set the milestone dates and the expectations for each milestone (API freeze, code freeze, changes now require two approvals, etc). We will decide whether to use a strict +1, +2 week milestones or whether to use a rolling milestone build - and in either case, the process we are going to use to make it work.

Nick wonders if we ought to have more steps between +0 and Release -- he'd like to see at least +3 and +4 added.

Ian wonders if for Ganymede would it be possible to plan the release to happen on a Wednesday? Having the release on a Friday makes it a bit more complicated to respond to any critical bugs. It would also allow us to issue a press release at the same time as the release. (Issuing a press release on Friday is sub-optimal if you want anyone to actually report on it.)

As currently posted in Ganymede Milestones and Release Candidates, there are 3 Tuesdays, one Friday (M4 Jan 11), and a final GA date on a Monday (Jun 30). Suggest the remaining unscheduled RC dates fall on Mon/Tues as well. --nickb 11:38, 5 October 2007 (EDT)

User Interface Guidelines

Bjorn is trying to arrange a report from the User Interface Best Practices Working Group to see if the guidelines are in sufficient shape for us to adopt for Ganymede. Perhaps a must do? And if so, how to we evaluate conformance? What are the rules? Discuss Mike and the Board's email [1]

Bob Fraser (UIBPWG lead) says: I am happy to appear and provide an update. Short answer:

• The UI BP Working Group will be able to come up with a “developer UI checklist” of about 10 items that is meant to be measurable and actionable. (We are not sure these will all fit the bill as a “must” but will be good enough for “should”.)
• The group will also provide a fuzzier list of “Top 10 UI Guidelines” that represent the spirit of UI development in Eclipse although the exact number is unclear
• The group feels pretty strongly that we [will not be able | do not want] to be in the business of enforcement.
  • Our recommendation is to handle this in a manner similar to API violations. You are judged in aggregate at various release reviews.
  • We hold regular meetings and any meeting is an opportunity for a UI walk through with discussion and feedback from the team. In fact, we would encourage any Ganymede project to take advantage of this.

Ganymatic

Bjorn will describe the Ganymatic build system and how you will contribute your project.

Brand/Trademark

Just a note that the Eclipse project name policy defines "Eclipse Ganymede" as an Eclipse Foundation brand/trademark for the benefit of the Eclipse community. This means that the Eclipse Foundation (a.k.a. the EMO) controls where the trademark is used, how it can be incorporated in corporate advertising, etc.

Supported Platforms

The BIRT team suggests: There should be a set of supported platforms that all participating Eclipse projects agree to support. With the amount of inter-dependence between Eclipse projects, letting each project decide on its own will cause more confusion in the community. An example would be java 5 support in Europa. BIRT wasn't planning on requiring it, until we were surprised and forced to by WTP and EMF deciding without consulting us.

At the very least, let's avoid surprises. Better yet, let's work on a process by which we can collectively decide to add or remove supported platforms.

I agree, it's important to let people know about changes like these, and IMHO, we did. See EMF 2.3 Plan History for details. We gave people ample time between posting the plan and committing the changes (over 4 months), so that objections could be raised -- and none were. If we could have done better, please let us know how. --nickb 11:33, 5 October 2007 (EDT)

I want to add that BIRT project is aware of the change of requiring Java 5 support in Europa. The BIRT PMC has discussed this topic, see this meeting minute [2] and agreed to supporting Java 5. Some project members might have expressed strong opinion about this requirement, but the project as a whole did reach an agreement. --wli

Packages

The Europa releases included four packages on the download page. This proved to be quite successful and we're planning to do at least the same thing for Ganymede. However one critique of the packages last year was that there was inadequate cross-project testing within the packages. So this year the projects that are incorporated into the packages need to agree to do some cross-project testing. Specifically, they need to agree to do their usual testing with the package rather than just with their own project image.

Internationalization

Perhaps a Babel project update. At least a discussion of how projects would like to (scripts?) contribute to, and consume, the Babel translations.

Community-Based Testing

What can we, as leaders of Eclipse projects, do to encourage more community-based testing? I've been bringing up the idea of a CPAN-like testing system [3] for Eclipse for a number of meetings, but I'd like to do more than talk. Let's discuss options that do not involve big new mandates on the projects and yet get our community more involved in testing the Eclipse packages and distros.

Discussion

• How can we make Ganymede better than Europa?
• Should we agree to rules about conformance UI guidelines? About framework integration at the UI or API levels?
• How do we guarantee early adoption of intermediate milestones of between projects rather than waiting for last minute integration testing?
• How do we ensure API cleanliness (i.e. not relying on other project's internals)?
• Concerns about the Eclipse Top-Level Project splitting streams (3.x vs. 4.0)?
• Performance and scalability. Is there consensus ? Actions to improve ? Measurements ?
• Enforcement:

A line in Ganymede plan says "Unlike the somewhat lax enforcement of previous years, the EMO will remove projects that do not meet the required constraints."

Since such issues often involve a cost-benefit analysis or trade off, I suggest we build-in a Planning Council mechanism that allows for reasonable exceptions. Besides allowing for exceptions, this might help avoid being too cautious on saying what is "required". For example, my suggested wording would be, "If projects do not meet the required constraints, they will be removed from the Ganymede release unless

1. The project applies for an exception that is reviewed and approved by majority vote of the Planning Council (that is, majority vote with no substantial objections).
2. The project has a plan for rectifying the non-compliant item by the next coordinated yearly release. Exceptions can not be granted two years in a row -- either compliance will be achieved, or the rule changed.

(added by David Williams 10/30).