search

eclipse-platform / eclipse.platform.resources

Eclipse Public License 2.0
3 stars 18 forks source link

Revert "Improve IFile.getLineSeparator() API" #160

Closed jukzi closed 2 years ago

jukzi commented 2 years ago

Reverts eclipse-platform/eclipse.platform.resources#159

mickaelistria commented 2 years ago

Jorg, I'll revert that. And please don't re-revert. You quick agreement on some bad API with another committer is not sufficient to make the API acceptable. Following existing patterns and OO principles is more important.

jukzi commented 2 years ago

Jorg, I'll revert that. And please don't re-revert. You quick agreement on some bad API with another committer is not sufficient to make the API acceptable. Following existing patterns and OO principles is more important.

Mickael, the same to you. you will follow the princibles of eclipse please that every commiter has the same power and you had been outvoted.

mickaelistria commented 2 years ago

Mickael, the same to you. you will follow the principles of eclipse please that every commiter has the same power and you had been outvoted.

I was not outvoted on https://github.com/eclipse-platform/eclipse.platform.resources/pull/159 , you're the only one who argued against it. I didn't bring it publicly to other project leads aa I thought that you would have the capacity to understand there are OO patterns and practices to follow for sustainable API, and I hope you already understand how important and difficult API maintenance can be to follow those patterns over just starting a new way to doing. Sure, it's annoying to get some work you've done reverted or reworked, but we've all gone through that and please show the maturity of accepting it graciously instead of interpreting it like an aggression.

akurtakov commented 2 years ago

Reverting patches is not the way to get things done. If committers disagree - discussion happens at the Project Leads level. If there is still disagreement issue should be brought to the PMC and every committer incl. project leads have to play by that decision. After the procedural guidelines, let's go to some technical such: This commit missed the point why the revert happens entirely. It's been documented at https://github.com/eclipse-platform/.github/wiki/PMC-project-guidelines#commit-messages and reiterated last week via https://www.eclipse.org/lists/eclipse-dev/msg12031.html . Please make sure to behave accordingly!!!

akurtakov commented 2 years ago

For the PMC: See also https://github.com/eclipse-platform/eclipse.platform.resources/pull/161 .

vogella commented 2 years ago

Reverting patches is not the way to get things done. If committers disagree - discussion happens at the Project Leads level. If there is still disagreement issue should be brought to the PMC and every committer incl. project leads have to play by that decision.

+1, @akurtakov we should also document this procedure in https://github.com/eclipse-platform/.github/wiki/PMC-project-guidelines

akurtakov commented 2 years ago

After discussing at the PMC today we went to writing short "committer disagreement resolution" section for cases like this one. See at https://github.com/eclipse-platform/.github/wiki/PMC-project-guidelines#committer-disagreement-resolution , it's shortened version of https://www.eclipse.org/projects/dev_process/ . There are few issues here:

Please follow these rules in the future to prevent cases like this one.

waynebeaton commented 2 years ago

The Committer Disagreement Resolution is at odds with the Grievance Handling section of the Eclipse Foundation Development Process which states (in part):

When a member has a concern about a Project, the member will raise that concern with the Project’s leadership. If the member is not satisfied with the result, the member can raise the concern with the parent Project’s leadership. The member can continue appeals up the Project Leadership Chain and, if still not satisfied, thence to the EMO, then the executive director, and finally to the Board of Directors. All appeals and discussions will abide by the guiding principles of being open, transparent, and public.

The exact definition of "member" is not clearly defined and it is not clear from context (I'll bring this to the Architecture Council's attention). The EMO interprets this to mean any committer (committers are mostly all members of the Eclipse Foundation, so this interpretation covers pretty much every practical definition of "member").

All of this is to say that the PMC's decision isn't final. It would be, in my mind, highly unusual for the EMO to override the PMC, but the option to escalate is available.