3 ms·

When there are hundreds of branches, not just feature branches but real long-lived development branches, and pull requests are managed the way they are in the L

When there are hundreds of branches, not just feature branches but real long-lived development branches, and pull requests are managed the way they are in the Linux kernel (chain of trust all the way up to Linus).. "Do the mass replace" becomes quite non-trivial I imagine.

kragen 5y ago
This strategy handles that fine as long as none of those branches lasts from before step 2 until the optional step 6. You pull from a long-lived branch, get a compile error because it calls select_nospec, do the replacement at that callsite, and commit. A headache but a manageable one. If you want to backport new features to old stable kernel versions, you can include a patch supplying select_nospec_unsafe as a synonym for select_nospec.
aliswe 5y ago
The branches wont compile until you fix every instance though, so its not that risky. just a bit messy.
- mamcx 5y ago
  And if the original version is not deleted in step 2 but after the final, then nobody break!
eru 5y ago
Depends on who you want to put the burden on? It's relatively easy to do the mass replace in master. You leave the burden of the replacement in the other branches to people who own those branches. Set up an automated script, to keep the 'unreplaced' version out of master (and people can also use that script to check their own branches). Not sure if that counts as non-trivial, yet? There are probably some other trade-offs involved. The people running kernel development ain't idiots.
- tjoff 5y ago
  > Not sure if that counts as non-trivial, yet? Assuming perfect tooling and infrastructure doesn't sound like it necessarily have to be a big deal. But, how far into fantasy land are we? How much effort would be required to get there? Is this and all similar problems large enough to justify it? Is adequately tooling and infrastructure even possible? Does that make proposed changes, such as moving to C11, order of magnitudes more difficult?
mamcx 5y ago
I not arguing is effort-free, but is effort-minimal. The idea allows, at most, one or two major steps, the first and the biggest is as simple as is possible and can be done in one go, and have zero possibility of breaking. The only major issues is that the change is let half-way. But that is only possible with MAJOR undisicpline. --- The major point, to me, is that this EXCESSIVE fear of breakage is not good. Yes, making upgrades is pain, but you CAN make the pain tolerable with some planning. Refactoring is like exercise for code: Everyone dislike the idea of excessive, but is GOOD. And lets be honest, among all the things that could requiere a refactoring, this case is on the most simples of the simples scenario..

kragen 5y ago

This strategy handles that fine as long as none of those branches lasts from before step 2 until the optional step 6. You pull from a long-lived branch, get a compile error because it calls select_nospec, do the replacement at that callsite, and commit. A headache but a manageable one. If you want to backport new features to old stable kernel versions, you can include a patch supplying select_nospec_unsafe as a synonym for select_nospec.

aliswe 5y ago

The branches wont compile until you fix every instance though, so its not that risky. just a bit messy.

mamcx 5y ago
And if the original version is not deleted in step 2 but after the final, then nobody break!

eru 5y ago

Depends on who you want to put the burden on? It's relatively easy to do the mass replace in master. You leave the burden of the replacement in the other branches to people who own those branches. Set up an automated script, to keep the 'unreplaced' version out of master (and people can also use that script to check their own branches). Not sure if that counts as non-trivial, yet? There are probably some other trade-offs involved. The people running kernel development ain't idiots.

tjoff 5y ago
> Not sure if that counts as non-trivial, yet? Assuming perfect tooling and infrastructure doesn't sound like it necessarily have to be a big deal. But, how far into fantasy land are we? How much effort would be required to get there? Is this and all similar problems large enough to justify it? Is adequately tooling and infrastructure even possible? Does that make proposed changes, such as moving to C11, order of magnitudes more difficult?

mamcx 5y ago

I not arguing is effort-free, but is effort-minimal. The idea allows, at most, one or two major steps, the first and the biggest is as simple as is possible and can be done in one go, and have zero possibility of breaking. The only major issues is that the change is let half-way. But that is only possible with MAJOR undisicpline. --- The major point, to me, is that this EXCESSIVE fear of breakage is not good. Yes, making upgrades is pain, but you CAN make the pain tolerable with some planning. Refactoring is like exercise for code: Everyone dislike the idea of excessive, but is GOOD. And lets be honest, among all the things that could requiere a refactoring, this case is on the most simples of the simples scenario..