WTH, why does it take more than half a year to get your PR reviewed by a core developer?

I hear the sentiment of what everyone is saying here. I have a foot in both camps by reviewing a lot of these PRs and also waiting sometimes >1yr for my own PRs to be reviewed.

My best advice is to keep your PRs short. A short, simple PR will get reviewed more quickly. It raises fewer questions, has lower risk, and is much less likely to become complicated or conflict with anything else. Less than 100 lines automatically gets the ‘short PR’ tag. If you can break a 600 line PR into 10x 60line PRs, it will be way quicker, as you are not asking for such a bulk time commitment from the reviewer.

Second piece of advice - put yourself in the mindset of the reviewer. They are just another human. Make the description really clear, explain what you are doing and why. Don’t give them lots to figure out. If you are doing something that might break things, describe how you’ve mitigated the risks.

Lastly - be the change you want to see. While you are waiting, review some other people’s PRs. They will value it and often return the favor.

Pinging your PR or tagging people is not a good idea unless there is a specific reason for urgency such as something else being broken. Many reviewers will de-prioritise overly pinged PRs to avoid encouraging this behaviour.

In case anyone is not aware, this is the list of open PRs for HA core (currently over 500), the default sort is newest first. I recommend looking at where your PR is on this list before insisting that you’ve waited an unreasonably long time.

Thank you for your contributions (and your patience!).

2 Likes

Respectfully, your post comes off a bit “privileged”. Have you ever owned/maintained a project as large as home assistant with this breadth of integrations without expecting compensation? Some things I’d counsel you on personally:

  1. This project has a high amount of PR contributions.
  2. Your personal PR isn’t special just because you wrote it.
  3. Your personal PR isn’t “free code”. It will have to be modified to be better quality, potentially change design, etc. If you’re a developer you should know PR’s aren’t the finish line. They’re the half way point. You have a proposal that takes work to be production ready.
  4. How small are your PR’s?
  5. How good is your code?
  6. Have you looked into what you could do to start reducing the overall piles of PR’s instead of whining yours isn’t being addressed?

I suspect you’ll change perspective after you’ve developed 15+ years and/or get some more personal hobbies that consume your personal time.

2 Likes

To whom are you refering to?

1 Like

My 2c, solution is not to review faster or more, solution is to have the HA platorm clean from integrations,
Have all integrations managed by HACS,
Have more strict rules to tegister custom components to HACS with automation tests (as part of pre-commit), and when there is a breaking change that requires opening code of many components it will be easy to notify the developers of that component as they are registered with their repo in HACS.

@isomer

Once your project gets approved, it’s pretty much instantaneous in HACS. There is no review process. Getting it approved is the bottleneck.

Of course that’s a double edged sword. Since no one reviews your code, as the project owner, it’s your responsibility to review it.

1 Like

Forcing moving to HACS is sweeping the issue under a carpet aka failure, it is not a solution. HACS grew into a somewhat close to must-have for HA. HACS also carries a lot of unusable stuff, however it isn’t relevant to the point. There’s enough integrations which are used instead of their core counterparts, sometimes, even because of the bugs and instabilities in the core ones. It’s effectively a claim that devs give no stability guarantee for integrations in HA.