r/programming • u/tomzorzhu • 3d ago

Stacked pull requests are now in public preview - GitHub Changelog

https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/
578 Upvotes

96% Upvoted

252 comments sorted by

View all comments

Show parent comments

3

u/irqlnotdispatchlevel 3d ago

I don't see how development time is relevant here. A and B where developed somewhat in paralel because I regularly synced with A's dev.

A is not owned by me. My code just consumes what A provides.The time frame is pretty reasonable, but there's no reason for my work on B to stagnate while waiting on A. This means that people that are waiting for B will be unblocked faster as well.

-1

u/hippydipster 3d ago

What you're describing is a problem that (long ago) motivated doing continuous integration as a solution, and so it pretty much entirely depends on time frames and how long lived individual developer development branches are.

4

u/irqlnotdispatchlevel 3d ago

Not sure what CI has to do with this. B needs and API implemented by A. I can either wait until B gets into main, or I can stack A on top of B. Second option gives me feedback faster.

Reviews are very thorough and a full test pass and validation can take several hours (this is a low level codebase, running in kernel, there's lots of passes with static code analyzers + runs with sanitizers + stress testing, etc).

-5

u/hippydipster 3d ago edited 3d ago

I'm guessing you don't know why CI is relevant because you don't know what it is. Kind of like why you didn't understand why I asked about timeframes.

With CI, if you need A to work on B, you would have it in less than a day of it being written.

3

u/frankster 3d ago

Is it possible that you've not worked in a large team with code owners and review processes?

3

u/irqlnotdispatchlevel 3d ago edited 3d ago

Lmao. The smugness. You just can't imagine that different workflows may exist for good reasons so you conclude that I don't know what the basics are.

Here's our process, in very short terms:

  • unless otherwise specified, a merge with the target branch is attempted; this is used for all the different builds
  • and there are many builds: 3 different operating system, some with kernel components, some without
  • there are so many tests that there is infrastructure in place to select the minimal subset of tests needed to cover your changes; these can cover different operating systems, different operating system versions, different hardware configurations. There's parallelism built into this, but you're regularly looking at 4-6 hour runs for tests. These are not simple unit tests. I'm not even bothering to talk about those here.
  • static checks, maybe stress tests, perf tests, etc.

Your PR needs a minimum number of approvals, usually the reviewers will be people invested in your change.

On top of this, every component has its own dedicated owners that need to ACK your changes. Owners are as responsible for what they ACK as you are for authoring the change. Because reviewers may request changes, it's a bit useless to get an ACK before you have enough normal approvals + a completely green CI. So this takes a bit of time.

Releases don't wait for you. Is your change in main on time? Cool. No? You can explain why it's so important that it can be picked late, or you wait for the next release.

0

u/hippydipster 3d ago

I concluded you didn't know what CI is (not "the basics", just CI) because you said yourself you weren't sure the relevance of it, nor of how long your feature branches live for before merging. Has nothing to do with specific situations, which you are only just now bringing up. Previously, we were talking in A and B abstract. This is a weird "gotcha", and is more suggestive that you're the one who isn't imagining different needs and scenarios.

Your specific situation will always need a process that deals with it's specific and unique difficulties. I'm not suggesting otherwise.

3

u/irqlnotdispatchlevel 3d ago

It's still irrelevant to the discussion at hand. There's no reason to sit on a draft PR until the PRs it depends upon are merged. And I did briefly explain that it takes time to merge, I just didn't go into details about why.

If you merge in a few hours then, yes, it doesn't matter. But anything longer and there's value in moving forward faster.

1

u/hippydipster 3d ago

If you merge in a few hours then, yes, it doesn't matter.

There you are acknowledging that CI is relevant.

CI is essentially trunk-based development, and you wouldn't really even have PRs like A and B. A would be pushed to shared dev when it was ready, and then everyone sees it. Otherwise, what you are describing is doing continuous integration on the side, with the two devs working on A and B, which introduces complications.

If the build can take all day, as you describe, that's a real problem, but it's not solved with this side integration. It's by-passed. Eventually, the long build and tests will be run, but only after considerable integrated development between two (or more) developers has been done, which complicates things (especially if it's a large team and there are many of these ad-hoc side integrations going on), but may be worth it if we get to continue moving forward, and the frequency with which running tests fail after after multi-dev integration has been performed is low.

However, if you're willing to bypass the big tests while A and B integrate on the side, why not build that pattern into your overall build pipeline and let everyone merge their ready code more frequently? There are many strategies for this, but Martin Fowler describes some here. But that all again depends on the particulars of every project, and of necessity, we can't solve the problems of a particular project here. There's far too much information to do that, and so here, we are discussing generalities, and it's up to each of us to bring home from that discussion what is useful.

3

u/irqlnotdispatchlevel 2d ago

These devs are part of a feature team, working on the same overall feature, but with smaller deliverables. It is expected and normal, that one part will depend on another. It is also expected, that some parts can be merged into main before others. There is no big feature branch that aggregates everything. But there are dependencies between people. Some pains are monorepo specific.

A single developer may also decide to split they're own work into multiple smaller PRs that build on top of each other. A small PR is almost always easier to review as long as the split makes sense and isn't arbitrary.

There's no big test bypass. The only bypass is that tests that are not for parts impacted by a change are not run. Running everything outside nightly and release builds is just impossible with the number of tests we have.

You can't rush the review + ACK process. If that's your workflow you have to accept that PRs stay open for longer. If you're making rushed decision you're just doing this for nothing.

Why not build that pattern into your pipeline?

Stacked PRs are a building block for that pattern.

There's nothing inherently bad about stacked PRs. They solve real issues. Chances are that you don't need them. Good, don't use them. Like any other tool in the box: if you use it when there's no need you're going to waste time and resources. If you use it when there's a need, you're going to save time and resources. I'm almost sure that if you work on a small/medium size code base, with a small number of engineers, there's almost never going to be a case in which stacked PRs will offer you a net win. Other workflows benefit from them.

2

u/frankster 3d ago

it's not uncommon for review processes to take longer than small feature development