[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