|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'sstatus, 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.
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
Back to the top