| Re: [eclipse.org-planning-council] A suggested topic for PlanningCouncil Discussion |
|
Although I agree with Ed about his process observations, I want to
comment that I thought this discussion started out with the Board
desire to *improve* the quality of the release train for an integrated
end-user experience. I didn't think this was intended to become a
referendum on the release train projects individually (as I believe the
dev process/reviews, etc are designed to provide such guarantees...as
John points out), but rather how we were all going to get to the
jointly-desired result: a high quality end-user experience for the
release train. Scott Ed Merks wrote: Mike, I didn't suggest giving up. But I am suggesting that I will not personally be on a quality police force. I would be much happier with a growing release train of ever improving quality. If we want to start kicking off the train cars we thing are crap, I believe this process will break down, especially considering that folks downstream from crappy cars will drop of by transitivity... I'm also not sure that 50 small projects are any different form 25 projects of 1/2 the size, so I think this focus on the number of projects is misguided. All that matters is quality not quantity and there are lots of things we could do to improve the quality. And it's not just the code we ship that affects perceptions. For example, some projects might consider paying more attention to their newsgroups... 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/01/2007 04:24 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 do not buy the argument that since you cannot measure quality objectively you should just give up. And yes, some mature projects could fall below this hypothetical bar. But as far as I'm concerned shipping a smaller, higher quality release train would be just dandy.-----Original Message----- From: Ed Merks [mailto:merks@xxxxxxxxxx] Sent: Thursday, November 01, 2007 4:06 PM To: mike.milinkovich@xxxxxxxxxxx; eclipse.org-planning-council Cc: 'eclipse.org-planning-council'; eclipse.org-planning-council- bounces@xxxxxxxxxxx Subject: RE: [eclipse.org-planning-council] A suggested topic for PlanningCouncil Discussion Mike, We don't have a bar for measuring quality objectively so that makes setting a bar for that extremely difficult. How could we measure this and wouldn't some mature projects fall below this bar? I also don't think it's reasonable to assume that incubating things have low quality nor to assume they have CQs that we must cut back on; mature projects seem to generate an awful lot of CQs all on their own. I very much share your sense of concern about quality but I see no solution for policing it. Peer pressure is the only viable solution I've heard so far. Given resource from the foundation itself, e.g.,for testing or usability analysis, I'm sure a lot more could be accomplished, but if that resource is already streched just by the IP load, that doesn't seem a viable alternative either. I think we're all ears for solutions... 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/01/2007 03:55 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> Doug, Doug, Ed, et al, What you are suggesting is an even lower bar than what we have had in the past. At least on paper, if not in practice. The problem with this approach is it means that the release trains just get bigger and bigger and with no incremental improvement in the overall quality of what?s coming from Eclipse. Shipping a big bag of stuff that doesn?t work together is not going to help us build a reputation for quality. It will destroy it. And once you have destroyed a reputation for quality, it can take a generation (e.g. ~20 years) to get it back, if ever. As a purely practical matter, I honestly doubt that the Eclipse Foundation as the IP resources to review and approve all the CQs to ship 30 projects on the same day. So if you guys don?t come up with some rules that raise the bar and limit who has the process maturity and quality to get in, don?t get mad at me for making rude and arbitrary decisions J I completely understand that what you?re recommending is the simplest and easiest approach. But IMHO (a) it?s the wrong thing to do for the Eclipse community and (b) it is unlikely to work in practice. Mike Milinkovich Office: +1.613.224.9461 x228 Mobile: +1.613.220.3223 mike.milinkovich@xxxxxxxxxxx From: eclipse.org-planning-council-bounces@xxxxxxxxxxx [mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of Gaff, Doug Sent: Thursday, November 01, 2007 2:32 PM To: eclipse.org-planning-council Subject: RE: [eclipse.org-planning-council] A suggested topic for PlanningCouncil Discussion All, As far as I?m concerned, the only reason to kick a project off the train is if they consistently fail to build and update their site at each milestone. Simply put, the ejection is because ?Project X keeps holding up the release.? Furthermore, I think it should come to a vote by all of the projects on the train to kick a single project off. Everything else should be a strongly encouraged optional requirement, and we should use public humiliation to police those requirements, e.g. ?I noticed that Project Y is not optimizing their jars, shame on you. Please fix it.? Clearly there are technical must do?s that physically put a project on the train, and they should be stated as such. Bottom line, I think we should err on the side of inclusion, and leave it up the projects to prove that they can or can?t keep up with the milestone schedule. If they can?t keep up, then their processes aren?t mature enough. Doug G From: eclipse.org-planning-council-bounces@xxxxxxxxxxx [mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of Scott Lewis Sent: Wednesday, October 31, 2007 5:17 PM To: eclipse.org-planning-council Subject: Re: [eclipse.org-planning-council] A suggested topic for PlanningCouncil Discussion Hi Bjorn, Bjorn Freeman-Benson wrote: Doug, (and everyone) I agree - if there are no people or people hours, there will be no code, no matter how much the Board wishes for it to happen. One could argue (I have argued) that the Board controls the people hours, so if they want to define a requirement, they should supply the resources, but somehow that logical situation doesn't always come true. Do you really think it would poison the community if there were a two- level train? I think it would poison the community to have a two-level train. I think we would quickly see different requirements and EMO treatment (and member company support) for the 'corporate-run' projects relative to all the other projects...those led by smaller companies and/or independents. Seems to me this would eventually lead to inequities that many committers would consider unacceptable for a merit-and-value-based community. A "meet all the requirements" level (the gold medal) and a "simultaneously release" level (the silver medal)? Maybe if the packages and the main update site contained the gold seal projects, but that the silver projects were also (if there was time to review the IP) available at the same time? It seems to me like this sort of classification would be inherently detrimental to 'silver medal' projects and differential to 'gold medal' projects. That is, it may say nothing about their usefulness, and/or value to be labeled as 'silver', but just the labeling by the membership and foundation will lead to end-user biases...with lower adoption, tougher distribution, etc., etc. It does seem to me that if the Board wants to mandate that the projects have to do more/other in terms of integration/testing, etc for the release train...and that the EMO should/must police/enforce the new rules...that there should be some recognition that this implies some support from the membership to do the work involved. There are many ways that I can think of to do this (contributing integration testing resources, allowing existing committers to work on related projects, etc., etc). Unfunded mandates don't really work IMHO...either for the committer community or for the EMO. Scott - Bjorn Doug Schaefer wrote: As for requirements, other than holding up the IP process I?m not sure what stick the EMO has to enforce projects meet the requirements. If projects don?t have the resources or the mandate from the employers of the resources to do the work, it doesn?t happen. And if you kick projects off the train because of that, that could poison the community. The best stick still is influencing and that involves good communication channels open between the requirers and requirees, and, of course, a reasonable set of requirements. -- [end of message] _______________________________________________ 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_______________________________________________ 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 |