6 ms·

I have been trying to upstream patches to kubernetes and etcd for about a year and ended up giving up. It is impossible to get someone from the project to revie

I have been trying to upstream patches to kubernetes and etcd for about a year and ended up giving up. It is impossible to get someone from the project to review my PRs, and since I cannot get PRs under my belt I can not become a maintainer either. My suspicion is that you get ghosted if you don’t have a @google or @redhat email address and really the only way to become a contributor is to be buddies with someone who works on the project already. I have considered going to one of the CNCF committee meetings and being like, hey you guys are not accepting new contributions which goes against your mandate. But in the end I just maintain local patches that don’t get upstreamed which is easier.

direwolf20 9mo ago
The CNCF may or may not take it seriously. They definitely won't if they don't know.
ahmedtd 9mo ago
Can you link your PRs here? Kubernetes is such a huge project that there are few reviewers who would feel comfortable signing off an an arbitrary PR in a part of the codebase they are not very familiar with. It's more like Linux, where you need to find the working group (Kubernetes SIG) who would be a good sponsor for a patch, and they can then assign a good reviewer. (This is true even if you work for Google or Red Hat)
- __turbobrew__ 9mo ago
  My PRs are submitted under my real name and my HN account is not under my real name, so I cannot share. For my etcd changes I did submit to the correct SIG, but nobody reviewed it.
perfmode 9mo ago
maybe you’ve already done this and I’m sorry if i’m telling you the obvious. You could analyze the repo to identify others who have modified the same files. and reach out to them specifically.
- Analemma_ 9mo ago
  I think if I were a random Google employee submitting Kubernetes patches at my day job-- i.e. not a project maintainer, but just someone in the K8s org chart-- I'd be kind of annoyed if I got cold-emailed asking me to help merge their patches. I'd probably trash that email and assume it was some kind of scam. I get that the current system isn't working, but I don't think you should just go emailing random committers, that seems likely to just piss people off to no benefit.
  - pklausler 9mo ago
    Github suggests reviewers to PR authors based on who's been modifying nearby code recently (ok, I don't know whether that's a general policy, but it happens to me all of the time). And for the past year or so I have been getting tagged to review more and more AI slop from newcomers to the project that we chose to maintain in public. I just immediately nope out of all reviews now if I don't recognize the submitter, because I don't scale enough to be the only actual human involved with understanding the code coming at me. This sucks for the newcomers who actually wrote the patch themselves, but I can't always tell. Put some misspellings in your comments and I'm actually more likely to review it!
socalgal2 9mo ago
I haven't seen your PRs and I don't work on those project. I have small projects that receive few patches. My experience of the few patches I have received though is they are 100% without exception, bad patches. Bad in that, without me putting an hour or 2 of work into them I can't just accept them. The most common case is no tests. The patch fixes an issue, but the issue exists because there was no test for the case the patch is fixing. So, to accept the PR, I have to download it and spend time writing a test. Other common experiences are bad coding practices and non-matching styles so I have two choices (1) spend 30-60 minutes downloading the patch, fixing these issues myself (2) spend 40-60 minutes adding comments to try to get the person who posted the PR to make their patch acceptable (40-60 mins includes the back and forth). More often than not, (2) never gets a response. The contributor's POV is they provided a fix and I should be happy to take it as is. I get that. At a certain level they are correct. But, these projects are hobby projects and I have limited time. So I generally don't do (2) because if they ignore the comments then it's wasted time, and (1) has the hurdle that I need to take an hour out to deal with it.
- xyst 9mo ago
  Wouldn’t it be best to ask contributor to reproduce the bug with a test rather than just completely ghost them? Companies such as Google have billions at their disposal yet still can’t figure out simple project management? Google of the past is no more, unfortunately.
  - pousada 9mo ago
    It’s not worth the time. You will spend uncountable hours of (unpaid) extremely exhausting labour talking to people who only care about solving their personal super specific problems. This is true for 90%+, there are exceptions but they are exceedingly rare Trust me I tried many many times. This has nothing to do with Google being evil it’s just one of the realities of maintaining a big open source project.
    - bruce511 9mo ago
      I'll add that for small projects, (and I suppose large ones) it's also a "unwelcome" task. Kinda like docs is. Open Source projects are typically done by people who like coding. Writing docs, reviewing PRs, "management" are all chores, not fun parts of the project. I manage a couple of projects that get submissions. Handling that is really not the fun part of my day. Fortunately I get very few. I can understand why ones that get a lot see it as a burden, not as the great gift the submitter thinks it is. Personally I don't want to spend hours each day reviewing PRs. That's not what I signed up for.
yicmoggIrl 9mo ago
> It is impossible to get someone from the project to review my PRs Sorry to say this, but this is natural. Writing patches is easy. Reviewing them is hard. Writing patches (and getting them accepted, merged) is rewarding and demonstrable (as a form of achievement). Reviewing patches, educating new contributors is sometimes rewarding, sometimes not (it's an investment into humans that sometimes pays off, sometimes doesn't), but mostly not a demonstrable achievement in either case. Therefore there is incentive to contribute, and hardly any incentive to review. This is why reviewers are extremely scarce in all open source projects, and why all sustainable projects optimize for reviewer/maintainer satisfaction, not for contributor satisfaction. As an external contributor, you just don't get to allocate scarce resources financed by some commercial entity with no relation to you. If you want to become a maintainer, or at least want others to review your stuff, don't start by writing code. Start by reading code, and make attempts at reviewing code for others. Assuming you get good at it, established project members should start appreciating it, and might ask you to implement some stuff, which they could be willing to review for you. You first need to give the real kind of effort before you can take it. And this is why "open development" is a total myth today. Resource allocation and work (chore) distribution are aspects of reality that completely break the wide-eyed, bushy-tailed "new contributors welcome" PR message. Opening up the source code (under whatever license) is one thing, collaborating with randos is an entirely different thing. Can you plan with them in advance? Do they adhere to your deadlines? Can you rely on them when things break? When there are regressions? > you get ghosted if you don’t have a @google or @redhat email address and really the only way to become a contributor is to be buddies with someone who works on the project already Yes, and the way to become buddies is to help them out where they are hurting: in their infinite patch review backlogs. Of course, that means you have to invest a whole lot of seemingly thankless learning, for the long run's sake. You have to become an expert with effectively nothing to show for it in the git history. It's totally fair not wanting to do that. Just understand that a ticket that remains open indefinitely, or an uncalled-for contribution that never gets reviewed and merged, may genuinely be better for the maintainers than taking on yet more responsibility for your one-off code contribution. > I have considered going to one of the CNCF committee meetings and being like, hey you guys are not accepting new contributions which goes against your mandate According to the above, I bet that "mandate" is a total fake; a PR move only. It does not reflect the actual interests of the organizations with the $$$, which is why it doesn't get followed. You are right that those orgs should at least be honest and own up to NOT welcoming newcomers or external contributors.
deleted 9mo ago
[deleted]
deleted 9mo ago
[deleted]

direwolf20 9mo ago

The CNCF may or may not take it seriously. They definitely won't if they don't know.

ahmedtd 9mo ago

Can you link your PRs here? Kubernetes is such a huge project that there are few reviewers who would feel comfortable signing off an an arbitrary PR in a part of the codebase they are not very familiar with. It's more like Linux, where you need to find the working group (Kubernetes SIG) who would be a good sponsor for a patch, and they can then assign a good reviewer. (This is true even if you work for Google or Red Hat)

__turbobrew__ 9mo ago
My PRs are submitted under my real name and my HN account is not under my real name, so I cannot share. For my etcd changes I did submit to the correct SIG, but nobody reviewed it.

perfmode 9mo ago

maybe you’ve already done this and I’m sorry if i’m telling you the obvious. You could analyze the repo to identify others who have modified the same files. and reach out to them specifically.

Analemma_ 9mo ago
I think if I were a random Google employee submitting Kubernetes patches at my day job-- i.e. not a project maintainer, but just someone in the K8s org chart-- I'd be kind of annoyed if I got cold-emailed asking me to help merge their patches. I'd probably trash that email and assume it was some kind of scam. I get that the current system isn't working, but I don't think you should just go emailing random committers, that seems likely to just piss people off to no benefit.
- pklausler 9mo ago
  Github suggests reviewers to PR authors based on who's been modifying nearby code recently (ok, I don't know whether that's a general policy, but it happens to me all of the time). And for the past year or so I have been getting tagged to review more and more AI slop from newcomers to the project that we chose to maintain in public. I just immediately nope out of all reviews now if I don't recognize the submitter, because I don't scale enough to be the only actual human involved with understanding the code coming at me. This sucks for the newcomers who actually wrote the patch themselves, but I can't always tell. Put some misspellings in your comments and I'm actually more likely to review it!

socalgal2 9mo ago

I haven't seen your PRs and I don't work on those project. I have small projects that receive few patches. My experience of the few patches I have received though is they are 100% without exception, bad patches. Bad in that, without me putting an hour or 2 of work into them I can't just accept them. The most common case is no tests. The patch fixes an issue, but the issue exists because there was no test for the case the patch is fixing. So, to accept the PR, I have to download it and spend time writing a test. Other common experiences are bad coding practices and non-matching styles so I have two choices (1) spend 30-60 minutes downloading the patch, fixing these issues myself (2) spend 40-60 minutes adding comments to try to get the person who posted the PR to make their patch acceptable (40-60 mins includes the back and forth). More often than not, (2) never gets a response. The contributor's POV is they provided a fix and I should be happy to take it as is. I get that. At a certain level they are correct. But, these projects are hobby projects and I have limited time. So I generally don't do (2) because if they ignore the comments then it's wasted time, and (1) has the hurdle that I need to take an hour out to deal with it.

xyst 9mo ago
Wouldn’t it be best to ask contributor to reproduce the bug with a test rather than just completely ghost them? Companies such as Google have billions at their disposal yet still can’t figure out simple project management? Google of the past is no more, unfortunately.
- pousada 9mo ago
  It’s not worth the time. You will spend uncountable hours of (unpaid) extremely exhausting labour talking to people who only care about solving their personal super specific problems. This is true for 90%+, there are exceptions but they are exceedingly rare Trust me I tried many many times. This has nothing to do with Google being evil it’s just one of the realities of maintaining a big open source project.
  - bruce511 9mo ago
    I'll add that for small projects, (and I suppose large ones) it's also a "unwelcome" task. Kinda like docs is. Open Source projects are typically done by people who like coding. Writing docs, reviewing PRs, "management" are all chores, not fun parts of the project. I manage a couple of projects that get submissions. Handling that is really not the fun part of my day. Fortunately I get very few. I can understand why ones that get a lot see it as a burden, not as the great gift the submitter thinks it is. Personally I don't want to spend hours each day reviewing PRs. That's not what I signed up for.

yicmoggIrl 9mo ago

> It is impossible to get someone from the project to review my PRs Sorry to say this, but this is natural. Writing patches is easy. Reviewing them is hard. Writing patches (and getting them accepted, merged) is rewarding and demonstrable (as a form of achievement). Reviewing patches, educating new contributors is sometimes rewarding, sometimes not (it's an investment into humans that sometimes pays off, sometimes doesn't), but mostly not a demonstrable achievement in either case. Therefore there is incentive to contribute, and hardly any incentive to review. This is why reviewers are extremely scarce in all open source projects, and why all sustainable projects optimize for reviewer/maintainer satisfaction, not for contributor satisfaction. As an external contributor, you just don't get to allocate scarce resources financed by some commercial entity with no relation to you. If you want to become a maintainer, or at least want others to review your stuff, don't start by writing code. Start by reading code, and make attempts at reviewing code for others. Assuming you get good at it, established project members should start appreciating it, and might ask you to implement some stuff, which they could be willing to review for you. You first need to give the real kind of effort before you can take it. And this is why "open development" is a total myth today. Resource allocation and work (chore) distribution are aspects of reality that completely break the wide-eyed, bushy-tailed "new contributors welcome" PR message. Opening up the source code (under whatever license) is one thing, collaborating with randos is an entirely different thing. Can you plan with them in advance? Do they adhere to your deadlines? Can you rely on them when things break? When there are regressions? > you get ghosted if you don’t have a @google or @redhat email address and really the only way to become a contributor is to be buddies with someone who works on the project already Yes, and the way to become buddies is to help them out where they are hurting: in their infinite patch review backlogs. Of course, that means you have to invest a whole lot of seemingly thankless learning, for the long run's sake. You have to become an expert with effectively nothing to show for it in the git history. It's totally fair not wanting to do that. Just understand that a ticket that remains open indefinitely, or an uncalled-for contribution that never gets reviewed and merged, may genuinely be better for the maintainers than taking on yet more responsibility for your one-off code contribution. > I have considered going to one of the CNCF committee meetings and being like, hey you guys are not accepting new contributions which goes against your mandate According to the above, I bet that "mandate" is a total fake; a PR move only. It does not reflect the actual interests of the organizations with the $$$, which is why it doesn't get followed. You are right that those orgs should at least be honest and own up to NOT welcoming newcomers or external contributors.

deleted 9mo ago

[deleted]

deleted 9mo ago

[deleted]