[
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
|
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.
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
