[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Hi, all,
The subject of "veto authority" has arisen in discussion of the OCL component, and I have been brought into that discussion. I have been trying to stay aloof because, IMO, I haven't any rights that would justify any influence on the process. However, perhaps I can help to allay some concerns.
First, I can say without reservation that I trust the integrity (moral and professional) of the proposed committer team as identified in Kenn's last e-mail. They have proven this through their interaction of various kinds, with me and amongst each other, and I believe that OCL will be in good hands with that team. To suggest *a priori* that their work is not to be trusted and that defensive measures are required is unfortunate, if not actually insulting.
From a practical perspective, there are a number of mechanisms already in place to protect the interests of all three Eclipse communities:
1. API Tooling: I instituted this as part of the OCL development process this winter in part because I was making (admittedly feeble) attempts to raise some committers from the contributor community. It isn't a complete solution, of course, as evidenced in the recent string-escape problem. But, it does help to assure several routine cases.
2. Eclipse bug process: raise API breakages as Blocker bugs. The committer team is bound by the Eclipse development practices, which are all about API. These bugs *will* be addressed.
3. Eclipse grievance process [1]: if problems like this go unaddressed, escalate to the PMC to get action.
It is my sincere belief that these mechanisms will ensure the integrity of the code and the needs of all three communities, without my help or that of a veto panel. I also reiterate my belief in the capability of the proposed committer team not only to protect the OCL component, but also to expand it and make it do cool new things that I never imagined.
Cheers,
Christian
[1]
http://www.eclipse.org/projects/dev_process/development_process.php#6_5_Grievance_Handling
