| Hi Scott,
Thanks a lot for your detailed answers!
From what you have written, I see no conceptual contradictions of what we believe is the right approach of cultivating an open source ecosystem. I would say we should not only approve Milan's committer request, but also see such requests for all team members who actively contributing to the project, so that it will be easier to go to the pubic repository as the primary development location in the near future.
@Martin, @Gorkem, @Wayne what do you think?
Regards, Nedelcho
On 20 Jun 2023, at 21:46, Scott Davidson <scott.davidson@xxxxxxxxxxxx> wrote:
Hi Nedelcho
Sorry for the late reply. See my answers below:
1. Are all committers currently part of one company (e.g. Broadcom)? Currently all committers are part of Broadcom. We are actively pursuing adoption of the extension with a varying degree of success. We are hoping more contributors will follow. This is true for those external to Broadcom and internal but outside our area. 2. Is it possible someone outside to contribute directly to the public repository and do you expect this at all? It is possible and we are hopeful to get more people involved.
3. Why Milan needs to be a committer when e.g. Roman could merge all the PRs alone? Yes, Roman can merge all the PR. However, if Roman is on vacation or sick we need another person to do that. But more importantly, we feel that Milan has earned the right to the committer role with his existing contributions.
4. What is the responsibility of the committer in this case - is he/she is the one who actually reviews the code or just have to "push the button" relying on the "team work" behind? The committer reviews that the code that we will be pushing is aligned with our QA gates, like passing the Blackduck scan for vulnerabilities or unsecure, old dependencies, check that the readme and change log is updated and also builds the VSIX file which is published to Marketplace and OPen VSIX.
5. What is the reason for the project to be part of organization like Eclipse Foundation, proclaiming the benefits of what Wayne provided as "rules of engagements"? Several years ago we chose the Eclipse Foundation as we originally wanted to focus on organizations that were interested in exploring Eclipse Che as a hosted IDE. Che4z is a subproject of Eclipse Che.
I hope this answers your questions, but if you have more, just let us know.
Scott.
Hi Scott,
The decision is the easiest part... I have a few more questions about the process that the team follows which might bring more clarity for such cases: 1. Are all committers currently part of one company (e.g. Broadcom)? 2. Is it possible someone outside to contribute directly to the public repository and do you expect this at all? 3. Why Milan needs to be a committer when e.g. Roman could merge all the PRs alone? 4. What is the responsibility of the committer in this case - is he/she is the one who actually reviews the code or just have to "push the button" relying on the "team work" behind? 5. What is the reason for the project to be part of organization like Eclipse Foundation, proclaiming the benefits of what Wayne provided as "rules of engagements"?
I believe that the team members would be fine to start working directly to the public. This will be only beneficial for them and for the project. Please, let us know what they would decide first.
Regards, Nedelcho On 15 Jun 2023, at 22:06, Eclipse Management Office EMO via ecd-pmc < ecd-pmc@xxxxxxxxxxx> wrote:
The PMC needs to decide about the committer election.
Progress is what we're looking for.
Wayne
ok, thanks for the update Wayne.
What you outline here has merit. We will review what you've provided and figure out to what extent we can improve the 'openness' of the project. As you can imagine, it won't likely be a quick change. In the short term, what can be done with the committer request?
Thanks for your reply, Scott.
My observation is that the project team periodically creates a branch in the repository, populates that branch with five commits that based on the commit message contain "code", "tests", "documentation", "configuration", and "license" updates, merges that branch, and then deletes it. Based on this, I assume that they're doing their actual development elsewhere, most likely in a server that sits inside the corporate environment.
If this assumption is incorrect, or if I am missing something important, please advise.
The fundamental problem with the approach that I've observed is that it makes the project completely impenetrable to anybody who does not have access to the repository where the day-to-day work is actually happening. Making changes and contributing them back to the project is extremely difficult when the day-to-day evolution of the code is not accessible. That is, the project is cutting off most of their potential for contributions from outside of the core team themselves.
The open source rules of engagement in the Eclipse Foundation Development Process define three fundamental principles of open source development: openness, transparency, and meritocracy.
While this teams mode of operating is at least nominally transparent, it is not particularly open to participation by others, and without being open to participation by others it is impossible to develop any merit to earn privileges with the project. Note that I describe the team's practice as nominally transparent because the commit record doesn't actually tell a story about the evolution of the content, it just records that changes happened.
I am happy to discuss this further. It's important to me that committers and project leads understand why we have the rules that we have.
I've written some blog posts on this topic:
Wayne
Hi Wayne
Adding Gorkem here in case this email doesn't make it to these distribution lists.
There is no specific reason why this team is working this way. We don't necessarily 'force' a team to not work in this manner. If the team sees value in working this way, are continually improving, are engaged and happy, we don't see much upside in pushing them to conform to how other teams operate.
Scott.
Based on a cursory look, it appears that this is the only repository that's being used in this manner.
That is... it does appear that the project team understands the value of working directly in the public repository in most cases, but this repository seems to be a special case.
Scott, is there a reason why the team has adopted a "periodically throw the code over the wall" approach for the che-che4z-explorer-for-endevor repository?
Wayne
Adding Scott on CC because he is not on the PMC mailing list.
-- Gorkem
Hey Gorkem,
Thanks a lot for forwarding this, much appreciated.
I think I still need to understand in more detail. Does this mean the team is not really working on the GitHub project in the open, but pushing all the changes they made for a specific cycle via one PR into the public GitHub repo?
When looking at the public GitHub repo that was mentioned here, I can indeed see that someone from the team pushes a commit called "apply code changes“ every once in a while. From your description it sounds like those "apply code changes“ commits contain all the changes that went in for a specific timeframe. Are all those code changes in each "apply code changes“ commit authored by that committer who pushes that commit?
Would be great to get a few more insights here… :-)
Many thanks in advance! Martin
FYI...
---------- Forwarded message --------- From: Scott Davidson <scott.davidson@xxxxxxxxxxxx>Date: Thu, Jun 1, 2023 at 11:52 AM Subject: Re: [ecd-pmc] Fwd: PMC Approval required for Committer Election for Milan Melisik on Eclipse Che4z To: Gorkem Ercan < gorkem.ercan@xxxxxxxxx> Hi Gorkem
I can't send to that distribution group, the last email bounced back. Sorry to make you the middle man, but can you pass along my comments?
The team uses a big PR when a new release (1.x.0) is published because it is developed locally within our repo and then published. So you are seeing the result of the team's work. One person from the team publishes to Eclipse repo.
See similar comments and approach for previous commits, eg Roman or Nikolai publishing PRs:
Let me know if further info or clarification is needed.
Scott.
Thanks for the email Gorkem
Let me talk with the team in Prague tomorrow and get back to you.
Thanks, Scott.
I did not realize that this feedback has not reached the che4z project, and it looks like it has got stuck on their end.
Adding Scott for awareness.
-- Gorkem
Hey!
This committer election looks a bit weak to me. There is only one PR being referenced. Looks like the PR contains a whole bunch of things in it (which feels to me a bit strange as well to have one commit called "apply code changes“, which changes hundreds of files). But that is probably a question for the team how they structure their commits and code repo.
Any thoughts?
Cheers Martin
Anfang der weitergeleiteten Nachricht:
Betreff: [ecd-pmc] PMC Approval required for Committer Election for Milan Melisik on Eclipse Che4z
Datum: 11. Mai 2023 um 06:04:58 MESZ
ecd-pmc mailing list
ecd-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ecd-pmc
--
Scott Davidson
Sr. Principal Architect | Mainframe Software Division
Broadcom Software
office: 631.533.8407 | mobile: 631.708.6387
100 Baylis Rd | Melville, NY 11747
scott.davidson@xxxxxxxxxxxx | broadcom.com
-- Scott Davidson
Sr. Principal Architect | Mainframe Software Division
Broadcom Software
office: 631.533.8407 | mobile: 631.708.6387
100 Baylis Rd | Melville, NY 11747
scott.davidson@xxxxxxxxxxxx | broadcom.com _______________________________________________ ecd-pmc mailing list ecd-pmc@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ecd-pmc
ecd-pmc mailing list
ecd-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ecd-pmc
ecd-pmc mailing list
ecd-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ecd-pmc
--
The Eclipse Management Organization | Eclipse Foundation
--
Scott Davidson
Sr. Principal Architect | Mainframe Software Division
Broadcom Software
office: 631.533.8407 | mobile: 631.708.6387
100 Baylis Rd | Melville, NY 11747
scott.davidson@xxxxxxxxxxxx | broadcom.com
This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
--
The Eclipse Management Organization | Eclipse Foundation
--
Scott Davidson
Sr. Principal Architect | Mainframe Software Division
Broadcom Software
office: 631.533.8407 | mobile: 631.708.6387
100 Baylis Rd | Melville, NY 11747
scott.davidson@xxxxxxxxxxxx | broadcom.com
This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
The Eclipse Management Organization | Eclipse Foundation
-- Scott Davidson
Sr. Principal Architect | Mainframe Software Division
Broadcom Software
office: 631.533.8407 | mobile: 631.708.6387
100 Baylis Rd | Melville, NY 11747
scott.davidson@xxxxxxxxxxxx | broadcom.com
|
