RFC: Commit access for outside contributors #2958
as you may be aware, the
What do you think?
The text was updated successfully, but these errors were encountered:
As for me, I used "Automerge" label when I have some small change to commit, but I want PR to pass CI checks. So, I make PR, give it "Automerge" label and bot cares about PR, not me.
Next time, if I see what CI has failed, I will resolve that issue, or take no more care if CI succeeds.
At practice, there was cases when PR has approved maintainer review, but was not merged by anybody.
Also, this mades impossible to require review from two (or more) maintainers, when one checks code style and other can check implementation details. Should we give it up?
Will this change make it impossible to merge PR by maintainers w/o Code Owner Review? This unclear for me a bit.
"Code Owner Review" implementation can make things faster to merge, which is attractive for committers.
Thanks for your feedback. To clarify, my goal is to allow contributors to maintain "their" plugin without being blocked by us maintainers. Maybe we can achieve this with Github's owner concept alone, i.e. without involving the bot.
For example, consider this config:
We could then add "individual-author" as an outside contributor. This user should then be able to approve (and merge) changes to
The other example,
I just don’t want to catch a situation when maintainer will not be able to merge commit w/o code owner.
My expectation would be for Github to block the commit until you are happy and change the status of your review to
I absolutely understand that concern – I had the same concern every time I gave commit access to someone. My experience has been, though, that if you trust people they will repay you by behaving responsibly. That said, if it doesn't work out and we come to the conclusion that revoking commit access from an outside contributors will reduce work for maintainers, we can (and should) do that.
I don't know, is this issue is correct target for this write, but I found no other which suits better.
This week I found some time to continue work on Collectd project.
Last months I read all the messages in mailing lists and from Github, so I know that changes are in progress.
Today I noticed the fact, which is very improtant for me and for project: I see, maintainers can't merge theirs PR yourself.
I know, that reviews are good to check project policy, code quality, etc.
But by previous practice, I know what PR may remain without review even for years.
After I became project maintainer, I made many PR and many commits. Many of them was merged by me directly.
But today, when new strict rules are here, I'm not ready to write PR to put them under the cloth and
This is all I wanted to draw Team and Communty attention.
I think this is the right place for this conversation.
The implementation of per-plugin owners currently requires that we enable the "Require review from Code Owners" feature to make it work. We can only grant "write" permissions (i.e. commit access) to the repository as a whole. We then restrict what per-plugin owners can commit by requiring reviews from a "code owner".
This change is purely a side-effect and not the result of any misbehavior. I'm very happy with the work that you and all the other maintainers are doing.
Please keep in mind that this is an experiment. If, after a while (I'd say 3–6 months) we conclude that this is a net negative for the project, we'll modify or stop the experiment.
Agree with your comment on maintainers. You have been helpful.
One question on the experiment part. We as read plugin developers or code owners (for now), welcome this direction.
As for me, there is none of positive changes.
Also, I see negative changes against me (personally).
I made this PR 3 weeks ago. Last update was 1 week ago (just to restart failed CI check).
After changes, I have no such possibility, and I have to wait until the thunder claps.
@rpv-tomsk sorry to hear about your experience.
For Virt #3117 similar story. One of the commit author @rjablonx has contributed multiple updates. Both @rubenk and yourself have been providing valuable feedback. So want to ensure we go with you on it.
For virt #3116 one of the commit owner @anaudx has provided the review and approved the changes with in 2 weeks of having this PR. If you see there is a delay from our side please flag it and we will ensure we give high priority. I believe @anaudx is good to have this merged, but will let him comment and merge it.
We have seen similar challenge of waiting for "thunder claps" like you mentioned when there are very many issues/PRs to be accepted by maintainers. Our goal and hope, as commit owners, is to reduce the burden by helping accelerate the reviews in the community without side tracking the maintainers. Until we clear out a easy way of working together, this might seem some inconvenience. But we are definitely open to help and learn.
As per new PRs, we have few plugins in the works and going through internal reviews/approvals. So you would see more updates from us soon.
Let us know how we can make this easy for you.
"flag it" ?? ouch. I see nobody have responsibility.
I see this PR as not merged. That is all I see.
I can't do anything about it, because now I have no merge rights for my own changes.
Looks like the issue that you have trouble with is about merging any of your updates.
Do you have any specific suggestions to help both code owners and maintainers? :)
PR #3148 hang in status "ChangeLog Expected — Waiting for status to be reported".
Master branch CI checks failing for months due to failing Solaris checks (#2815).
As Developer and Maintainer, I'm not going to fight these systems and newly-added restrictions.
@octo, you really need to solve these CI problems.
Also, https://pkg.ci.collectd.org has no actual distributions supported, last is Debian Jessie, for example.
If you really want to bury The Project (thanks for founding it), please declare that explicitly.
I see no benefits from this experiment. I see no PR merged by "outside contributors".
I'm not able to understand, why you wait for 3 months to restore access for "inside contributors".
I'm not able to work on Project while all actions done are against this my work.
Another example: #3127.
When I had access, I could simply move one line of code into appropriate place.
Now, I should watch into opened PR and wait until someone’s attention, which possibly never happen.
At the risk of a) annoying people and b) coming across as a know-all: From the perspective of an outsider this workflow change (and probably breakage) looks like a serious problem. One of the more active developers pointed out that his contributions are hampered by the current configuration and expressed his concerns loudly. If there was a 'blocker' label, this issue would deserve it IMHO.
I always understood this change as additional possibility to get something merged, not as intention to remove people.
The issue mentioned here with "code-owners" approving a patch: that was apparently due to "code-owners missing write permissions in the repository and should be fixed.
Unfortunately, I don't have an insight, why approval of a trusted member does not trigger a merge through the automerge bot.
Anyways: the last thing we'd want is either to discourage or actively prevent people from contributing. If you feel that way, please speak out!
@rpv-tomsk Pavel, I've heard your concern, and let's see what we can do to fix it. Please bear with us.
There is declarations on words, and practice at reality.
As you can see, my question and "side effect" left w/o answer/fix from 21 Feb.
How do you think, how this affects my desire to continue work on project?
If this is not meant to be a rhetorical question, I assume you're demotivated and feel neglected. As said: let's try to get this fixed ASAP.
Meanwhile, please feel free to add me to your PRs, and I'm happy to review/merge them.
As per https://github.com/orgs/collectd/teams/trusted-contributors/members there are 8 members,
Let's look, how many comments/reviews I got in #3159 where I asked review from "Trusted Contributors"?
So, you propose me to write PR and wait. Wait. Wait and wait again. For months.
UPD: Thanks for your care on my PRs.
As you all can see, hiding behind good intentions, "TEAM" found new way to break Collectd development.
Not only administrative rules applied now, but technical too.
New "clang-format" rules prohibits to merge PR, even if no lines was added - see: #3214
To overcome this barrier, developer needs to run stupid contrib/format.sh.
You think your PR is ready, but it is not. That additional stupid work makes developers angry and not loyal to project.
That makes PR hard to review, so PR merge stops and develoment stops as result.
I see only these, one after another changes appear which breaks development flow and destroy the project.
I don't think this outcome is/was intended/desired at all. During working with the changed rules/setup we discovered the following issues:
I'm speaking about the same - our's time is the most valuable resource, so we should not spent it on fighting administrative and CI issues. Also, I think, nobody of us wants to spent time implementing feature and then throw out the result of the work just because lack of response. Yes, I know that is the problem 'code owners' tries to solve (add plugin owners ability to merge theirs changes), but that breaks things and puts them upside down.
Just looked into my PR history.
For example, PR 2819.
There was 4 days w/o any feedback, and I found this not funny to spent hours of work, so just do that merge myself.
Because I could.
When I could't:
(just some stats, I don't looked over all 135 my PR and don't included PRs where waiting was month or less).
opened on 19 May 2019. No any feedback for ~2months.
2391 - perl plugin: Added check of proper interpreter initialization.
~2 months of waiting, opened 2 Aug 2017 - merged 21 Sep 2017;
2388 - memcached: Persistent connections with IO timeouts
2 months of waiting, opened 31 Jul 2017 - merged 27 Sep 2017;
2385 - memcached: Fix hitratio reporting, add connections rate report
opened 30 Jul 2017, first review 26 Sep 2017
2377 - openldap: Fix crash on shutdown when openldap connection failed
2 months of waiting, opened 24 Jul 2017 - merged 22 Sep 2017
2232 - processes: Show real disk IO in addition to process IO (Linux only)
4 months of waiting, opened 29 Mar 2017, first review - 17 May 2017, merged 20 Jul 2017
2024 - ipmi plugin: Implemented IPMI LAN connection and plugin improved
11 months of waiting, opened 5 Nov 2016. First review 8 Oct 2017. Merged 10 Oct 2017.
I do that merge myself, that was my first merge as maintainer.
1622 - statsd, utils_latency: allow to reduce bin width
5 months of waiting, opened 20 Mar 2016 - merged 11 Aug 2016. 2.5 months before first review plus two months after, before PR merged.
1564 - disk plugin: send disk_merged,disk_io_time,pending_operations only when real data exists for device
2 months of waiting, opened 25 Feb 2016 - merged 24 Apr 2016;
1558 - Curl_xml: Custom names for plugin/plugin instances
7 months of waiting, opened 24 Feb 2016 - firstly reviewed and merged shortly after 29 Sep 2017;
Who of you likes to wait?