[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse.org-planning-council] A suggested topic for Planning Council Discussion
|
> -----Original Message-----
> From: eclipse.org-planning-council-bounces@xxxxxxxxxxx
> [mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of
> Doug Schaefer
> Sent: Thursday, November 01, 2007 3:36 PM
> To: eclipse.org-planning-council
> Subject: RE: [eclipse.org-planning-council] A suggested topic for Planning
> Council Discussion
>
> Yes. This is the best practical approach.
>
> But the question remains. How does the board get the projects to meet
> requirements? The world sees Eclipse as a whole. One bad piece impacts the
> perception of the others. The projects are little kingdoms with 99%
> autonomy. We need to figure out how to influence into that environment.
Without having to bring in Knuckles :)
> 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
> Ed
> > Merks
> > Sent: Thursday, November 01, 2007 3:04 PM
> > To: 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
> >
> > +1
> >
> > I agree. Very well said. We need to focus on what's needed to get out
> > the builds and ultimately the release and resort to peer pressure to get
> > folks who stray back in line...
> >
> >
> > Ed Merks/Toronto/IBM@IBMCA
> > mailto: merks@xxxxxxxxxx
> > 905-413-3265 (t/l 313)
> >
> >
> >
> >
> >
> > jograham@sybase.c
> > om
> > Sent by:
> To
> > eclipse.org-plann "eclipse.org-planning-council"
> > ing-council-bounc <eclipse.org-planning-
> council@eclip
> > es@xxxxxxxxxxx se.org>
> >
> cc
> >
> > 11/01/2007 02:49
> Subject
> > PM RE: [eclipse.org-planning-
> council]
> > A suggested topic for
> > PlanningCouncil Discussion
> > Please respond to
> > "eclipse.org-plan
> > ning-council"
> > <eclipse.org-plan
> > ning-council@ecli
> > pse.org>
> >
> >
> >
> >
> >
> >
> > +1
> >
> > Well said, and I think this strikes a nice balance between what should
> be
> > done and what can be enforced.
> >
> > Regards,
> > John Graham
> > Eclipse Data Tools Platform PMC Chair
> > Staff Software Engineer, Sybase, Inc.
> > http://dataplat.blogspot.com/
> >
> >
> >
> >
> > "Gaff, Doug"
> > <doug.gaff@windri
> > ver.com>
> To
> > Sent by: "eclipse.org-planning-council"
> > eclipse.org-plann <eclipse.org-planning-
> council@eclip
> > ing-council-bounc se.org>
> > es@xxxxxxxxxxx
> cc
> >
> >
> Subject
> > 11/01/2007 02:32 RE: [eclipse.org-planning-
> council]
> > PM A suggested topic for
> > PlanningCouncil Discussion
> >
> > Please respond to
> > "eclipse.org-plan
> > ning-council"
> > <eclipse.org-plan
> > ning-council@ecli
> > pse.org>
> >
> >
> >
> >
> >
> >
> > 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
> _______________________________________________
> eclipse.org-planning-council mailing list
> eclipse.org-planning-council@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
