[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [eclipse.org-planning-council] A suggested topic for Plannin gCouncil Discussion

Yes. Too bad I won't be there :(

Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, http://cdtdoug.blogspot.com


> -----Original Message-----
> From: eclipse.org-planning-council-bounces@xxxxxxxxxxx
> [mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of
> Mike Milinkovich
> Sent: Friday, November 02, 2007 1:22 PM
> To: 'eclipse.org-planning-council'
> Subject: RE: [eclipse.org-planning-council] A suggested topic for
> PlanningCouncil Discussion
> 
> I've been pondering this thread and wondering why this debate went off in
> the direction that it did. I came to the conclusion that --- as in so many
> things in life --- the root cause lies in a misunderstanding. Or a
> different set of assumptions. Or a miscommunication. Whatever :-)
> 
> Our history of doing release trains is relatively short. But we at the EMO
> believe that we have learned something over the past two years. And that
> lesson is that it is impossible to change the perception of the community
> on what the release trains mean. What I mean by that is that no matter how
> many times we tell people (including journalists) that the release trains
> are a bunch of projects which ship together, and that the main focus is on
> enabling adopters, the broader community resonates back that it is a
> single release and they expect things to work together. Or at least play
> nicely together.
> 
> In addition, the functionality expectations of developers have been
> raised. In 2001, JDT gave most Java developers what they needed. Now
> they're looking for a much broader set of functionality as the entry
> point.
> 
> So my observation is that as of this moment the community and the planning
> council have different ideas of what the annual release is. And IMHO the
> community's opinion wins. At least in the sense that it defines what we
> are expected to achieve.
> 
> Doug's suggestion that perhaps EPP is part of the solution is worthy of
> further exploration. My gut tells me that is necessary but not sufficient.
> EPP cannot solve all of the quality and integration issues on its own.
> 
> It should be a fun Planning Council meeting next week :-)
> 
> Mike Milinkovich
> Office: +1.613.224.9461 x228
> Mobile: +1.613.220.3223
> mike.milinkovich@xxxxxxxxxxx
> 
> 
> _______________________________________________
> eclipse.org-planning-council mailing list
> eclipse.org-planning-council@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council