Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wtp-pmc] 6/20/2007 EMO Planning Council Meeting Notes

These are my personal rough notes from the subject meeting ... I'm sure there will be some official ones published soon.


6/20/2007 EMO Planning Council Meeting Notes

We did decide on 9/28 and 2/29 as coordinated maintenance release dates for Europa.
We didn't specify detail, but the desire/need to have some staging (0, +1, +2) sorts of rollout
was stated. For maintenance, this is mostly to allow some progressive testing, as no one
should be "breaking builds" in maintenance.

Doug Gaff, Winriver  Eclipse Con Committee Chair, Discussed Eclipse Con Preliminaries

Sunday to Wednesday this time,
March 17th to 21st.
(instead of Monday to Thursday)
But maybe tutorials throughout, not just Sunday
And by the time the meeting was over, we
advocated Sunday to Thursday (so less parallel tracks).
Some discussion of price structure.
Will possibly have "any tutorial" pass.

Anyone know of any good keynote speakers we should approach?
(Doug had a list ... was just looking for others).

I am now Program Track lead for Web Tools (taking Tim Wagners place).
We'll do as last year, where PMC discusses/decides.


At end of day, much discussion on how to improve IP process. There were some constructive suggestions that came out of it, but I still think it's working fairly well,
and, as human nature is, any discussion of "how to improve" ignores the enormous improvements that have been made. (I recall when 'approval' was not even traceable!)



How to improve Ganymede?, especially how to get earlier integration, and earlier testing.
        Some advocated massive source builds, not necessarily to use the results, but to get improved, early compiler checking.
        But, not me. I think that will be more work that than anyone realizes, and will likely mostly reveal all-ready known problems in most cases.
        I advocated more "global," automated JUnit testing, automated performance testing, and "API scans" of some sort.
                For example, what are results of Platform's crisp performance tests when all of Ganymede is installed. (early informal tests shows lots of problems).
                Even then, there is the problem of "who investigates the bugs" ... as can be more difficult with "everything loaded" and very time consuming.
        I also advocated using "distributed testing" to get better platform coverage and more varied installation testing. There was some "fear" of this as being too hard, etc.
        But TPTP was interested in investigating and possibly supporting.
        It was proposed to have a cross-project workshop on using improved automated testing, such as TPTP to provide JUnit framework, coverage statistics, and data collection.
        Which would include performance and some sort of API scan.
        I advocated to at least has a Ganymede requirement that each project publish their cross-project discouraged access warnings.

What value does Ganymede provide to projects?
        Simultaneous Release still seen as primary benefit to projects.
        Many other potential things, such as "improved user experience" are seen requiring a LOT of extra work.
        Some mentioned it's "near impossible" with Eclipse Foundation's current project structure, since there is no one responsible for overall user experience.
        And, while a noble goal, some questioned if this was really needed, as some adopters and "add on" providers provide this service. (The Eclipse Foundation would say "yes, needed",
        the question is if all Adopters who provide committers would).

Some discussion that API freeze comes too soon.
But, this was discounted, since current early date is "only way", since after API freeze, there is an enormous amount of implementation testing/bug fixing, performance testing, documentation, etc, that is required. (that is, it's not only for early "stability", but also as the only known way to schedule work). Plus, it was pointed out, some exceptions are allowed, just takes more review and PMC approval.
* remember one of our early, initial WTP 3.0 planning activities should be to "push" on our non-API use to be sure it gets in platform requirements

Many raised the need more "fined tuned" dependancy schedule.
        Partially in terms of time, need more than +1 +2 weeks (such as +2 day intervals spanning 2 weeks, so there's 7 or so increments, instead of 2.
        And, not only on "complete project" granularity. (for example, WTP depends on DTP, but (parts of) DTP depends on WTP).
        * need improved dependancy tools, so we can tell programmatically, across 21 projects or more, what depends on what.
        ** post-meeting note: perhaps we need a better designated time to do "full install" testing. Currently it's assumed to do "as we go", but
        that's hard to do. Perhaps for one week after each Ganymede milestone, request projects do some "report"?
        ** post-meeting note: I didn't really have opportunity to mention that "end-game" schedule is "off" ... seems to allow/promote the base platform
        to stick to one-week rhythm, but then all upstream projects have "ever changing" rhythm (which is no rhythm) not to mention the Platform is coming out with
        RC3 when all others are still dong RC2, for example.

We will have a cross-project keyword in bugzilla, for bugs that appear only when the subject projects are both installed ... and the planning council will periodically review such bugs to be sure they are getting the attention they deserve.

3.4 vs. 4.0

        Some high level discussion of what might be in 3.4 (planning on going now) and what a "4.0" version of Eclipse might mean. But, the 4.0 version is "just an idea" at this point,
        and is partially to see if "Eclipse Platform" can be "more diverse" with committers.


Joint Planning/Board/Requirements meeting mostly focused on possible IP process improvements. End result was a working group was formed to continue to discuss and make concrete recommendations.


As a side note, even though I wasn't there, there were (only) 5 people at Requirements Council meeting (I think this is what they expected, but seemed small to me).



Back to the top