Trying to predict band splitting

[jmvalin]

No description provided.

[thirv]

I'm bit confused about the branches. You want a review on this PR in how it affects jmvalin/theta_cleanup, while that branch is used in another PR to main? Should PRs be layered this way because it seems difficult to interpret the final effects to main...?

[jmvalin]

I just thought it made more sense to already have the changes be one on top of each other, i.e.

main -> A -> B -> C -> D

rather than

       /-->A
main -/--> B
      \--> C
       \-> D

It's more logical in terms of development, it reduces the amount of conflicts, and it's necessary in some cases where PRs depend on earlier PRs. For example, among the current PRs, #17 requires #16 to work.

[thirv]

If you do a PR on top of an ongoing PR, doesn't this assume that the first PR works, or at least possible changes to the first PR during review would not affect the latter? Is it better to wait for the first PR to merge or you think this is not an issue?

[jmvalin]

Well, I'm assuming there's more than a 50% chance the PR lands in one form or another. Having all PRs based on main would also mean having to adapt as soon as something lands in main. There's no way to avoid rebase unless you only ever allow a single open PR to exist at any given time. In this case, I stacked the PRs to minimize the expected amount of complications. PRs #14, #15 and #16 are mostly independent (any of them can be applied separately), but they all change the same files, so I think this is simpler. As for PR #17 , that one just cannot exist without #16, so it couldn't be based on main even if I wanted to.

[thirv]

It is clear multiple open PRs must be allowed. Was just trying to learn why stacking is beneficial compared to making PRs to main and merging main changes as they appear. But no problem so far if this way is preferred.