Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Planning Council Agenda

Revision as of 11:39, 5 October 2007 by Codeslave.ca.ibm.com (Talk | contribs) (Supported Platforms)

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.

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?

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]

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)

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.

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 ?

Back to the top