[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
