[wtp-pmc] 6/20/2007 EMO Planning Council Meeting Notes

[David M Williams <david_williams@xxxxxxxxxx>]

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!) 

================================================

Ganymede

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). 

See 
http://wiki.eclipse.org/Requirements_Council
http://wiki.eclipse.org/index.php/RequirementsCouncil06TP

================================================