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.
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council