Hi Bjorn,
Bjorn Freeman-Benson wrote:
<stuff deleted>
Maybe the problem is that you fear that the definition of merit will
favor some projects over others?
Yes, I do. Merit can be defined a lot of ways.
But
wouldn't the public community
decision of the rules reduce that bias?
I'm not completely sure what you mean by 'public community decision of
the rules', but I have doubts that the rules will be community decided
and community enforced. As an example, the planning council, with all
due respect, doesn't very completely reflect the committer community.
Scott
Dave Steinberg wrote:
If anything, I'd say the problem is that people already have this
expectation, but it's not at all reality at present.
...what a distribution does
for you is provide some assurance that all the stuff works together.
... which is why they've limited the
packages they include in main.
We don't do that, which is the issue.
Exactly. I believe that is the other core point of this thread: our
current "simultaneous release" is seen by the community as "an
integrated tested distro". Either we should step up to that or we
should stop doing it, but we should certainly not (accidentally and
unintentionally) mislead our community.
Gaff, Doug wrote:
My comment is
that to meet this expectation requires an intentional plan with
dedicated testing resources.
This requires a board-level strategic decision and a member company
staffing commitment, and I think you need to help make that a reality.
Scott Lewis wrote:
But,
like Doug G, I think it requires some effort/commitment beyond what the
individual projects (or more accurately the committers for those
projects) can do by themselves/on their own, because fact is,
integration of a large system like Eclipse at a high bar of quality is
hard. It seems to me that that burden (integration testing, overall UI
improvements, etc) should be shared rather than delegated/mandated.
Scott Lewis wrote:
I just wish we could have some discussions about what to do about this
technical requirement that didn't eventually boil down to "committers
and EMO go do it".
Mike has told me that the Board has been very clear that the Eclipse
Foundation is not supposed to (thus not going to) hire people to do
integration testing, overall UI improvements, etc. thus either
committers on projects are going to do it, or it's not going to get
done.
Doug Schaefer wrote:
It could be
a good
mechanism to rally the projects behind raising the bar.
Excellent point - a carrot (raise the bar to participate in the
packages) rather than a stick (don't meet these requirements, don't get
in the big update site). I actually think we need both, although the
'stick' items from "Knuckles" should be around the mechanicals of
participation in the builds.
Doug Schaefer wrote:
The point is
to raise the quality
perception of Eclipse in the marketplace, i.e., beat NetBeans (and for
my
community, be as good as Visual Studio). Nothing changes to the train
and its
current operation. This is more an addition for those projects who want
and
need to work at addressing these issues.
The process
for managing these products
needs to be open just like everything else in Eclipse.
I agree.
Scott Lewis wrote:
But the last I checked, EF wasn't a business. So who decides who
doesn't 'make the cut'?
A community of committers, of course, just like for all other projects
at Eclipse. In fact, to be blunt vis a vis one of the core issues that
started this thread, a community of committers who put sufficient time
and effort in to making the "product" happen, not a set of Board
members who impose requirements without resources.
Doug Schaefer wrote:
At
any rate, we need some sort of organizational
answer to making requirements stick, or the exercise of defining them
won’t
seem like a great use of time either. J.
Say hi to "Knuckles" Freeman-Benson, your friendly neighborhood rules
enforcer :-|
Seriously, though, the community should decide on the rules and the
mechanism and that mechanism will probably involve the EMO enforcing
the rules with the community having a veto power - much like it does
now for other Eclipse process issues.
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
|
