[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@xxxxxxxx
> >              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