[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse.org-planning-council] A suggested topic for PlanningCouncil Discussion
|
Hi Ed,
Ed Merks wrote:
Mike,
<stuff deleted>
So while a two tiered system might rub some the wrong way, how else is
merit and quality recognized, or the lack of it reflected in a project's
status, than in some kind of tiered system?
Well, how about systematic community input? How about something (dare I
say framework? :), that allows packaging of different project's contents
into custom potentially-user-defined profiles?. How about leveraging
EPP, Maya, and/or p2 (or even getting [gasp] these projects to work
together for the good of all projects) in this respect?
I think alternatives exist here...and yes a two-tiered system does rub
me the wrong way...precisely because tiers are not 'level'.
I think Doug's suggestion is a
particularly good one. Perhaps if we take the EPP packaging one step
further and define clear owners for the packages, folks who will do quality
assurance and set standards for what's in the package and who will take
pride in producing a high quality result we can focus the issue away from
just who's on the train and who's not, and focus instead on the issue you
are outlining. I.e., how do we make sure that the user perception is that
part of what Ganymede produces isn't just a mishmash of projects, but also
a set of high quality product-like offerings...
Just for the record, like I think all concerned, I'm all for
improvements in quality and end-user experience for the release
train...and will back this up by doing the work involve for my project.
But, like Doug G, I think it requires some effort/commitment beyond what
the individual projects (or more accurately the committers for those
projects) can do by themselves/on their own, because fact is,
integration of a large system like Eclipse at a high bar of quality is
hard. It seems to me that that burden (integration testing, overall UI
improvements, etc) should be shared rather than delegated/mandated.
I'm all for getting away from who's on the train and who's not...but I
think a tiered structure quickly becomes exclusionary in a way that
doesn't seem (to me anyway), in keeping with EF openness, transparency,
and meritocracy.
Scott
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 313)
"Mike
Milinkovich"
<mike.milinkovich To
@eclipse.org> "'eclipse.org-planning-council'"
Sent by: <eclipse.org-planning-council@eclip
eclipse.org-plann se.org>
ing-council-bounc cc
es@xxxxxxxxxxx
Subject
RE: [eclipse.org-planning-council]
11/02/2007 01:22 A suggested topic for
PM PlanningCouncil Discussion
Please respond to
mike.milinkovich@
eclipse.org;
Please respond to
"eclipse.org-plan
ning-council"
<eclipse.org-plan
ning-council@ecli
pse.org>
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
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
