[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

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.

--

[end of message]


_______________________________________________ eclipse.org-planning-council mailing list eclipse.org-planning-council@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council