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
|
