4 ms·

Not the first or only project to do this. Spigot, a fork of the CraftBukkit minecraft server, uses a similar approach [0]. It allows to easily collaborate with

Not the first or only project to do this. Spigot, a fork of the CraftBukkit minecraft server, uses a similar approach [0]. It allows to easily collaborate with the upstream project (Just apply the feature's patch on current master). [0] : https://hub.spigotmc.org/stash/projects/SPIGOT/repos/spigot/browse https://hub.spigotmc.org/stash/projects/SPIGOT/repos/spigot/...

0x0 11y ago
Wouldn't it be better to just keep the changes in a branch in a fork off of the upstream master branch? I would think that git would do a better job at re-applying to newer releases (i.e. merging from upstream master) than what patch(1) can do?
- btown 11y ago
  This makes me think that automatic rebasing and test running as a service would be an interesting product. Continuous integration of upstream changes into your possibly proprietary downstream fork (for features or ports), with Travis running each time.... You could avoid the problem of divergent forks!
  - voltagex_ 11y ago
    I think you could probably make Travis do this itself - the script would be a bit gnarly though.
  - viraptor 11y ago
    This is possibly the hardest version control problem I ever ran into. Especially in projects which have a large number of changes upstream (100+ commits daily), I've only seen bad and worse solutions. The bad one is trying to follow upstream on each commit, notifying you every time some patch either doesn't work or doesn't merge anymore so you have to fix it manually. This still doesn't stop the cases where the patch in itself works, but doesn't make sense in the project anymore (some code moved around, tests still pass, but the functionality is not reachable). You also need a fair bit of architecture to test each of your patches with on each upstream change. The worse solution is taking a few days off every time a bigger release is out and porting all patches. It saves on the continuous testing infrastructure, but takes unknown amount of time and you may discover some functionality simply cannot be migrated anymore. You're also likely to introduce many more bugs with rushed development. I've been through planning something like this on a number of projects before. It's a lot of effort and it should be avoided as much as possible. I think the product you describe could be actually a really good idea, but a lot of it would have to deal with as clever annotations as possible - what broke, when did it work the last time, who's responsible for porting, what functionality does it provide, is it critical/optional, etc.
- kazinator 11y ago
  That would require someone to read a man page or two. Which they clearly don't need to do because, nearly self-evident proof: they memorized the gnu diff and patch ones twenty years ago, QED.
asiekierka 11y ago
Spigot does this for another reason: thanks to someone making the arguably stupid choice of using GPLv3 for a project linking to (propiertary) Minecraft source code, CraftBukkit has been DMCA'd by one of the lead developers over Mojang taking over the project when the lead dev team quit and is now essentially illegal to redistribute.
- belorn 11y ago
  Was it ever legal to redistribute the proprietary Minecraft source code?

0x0 11y ago

Wouldn't it be better to just keep the changes in a branch in a fork off of the upstream master branch? I would think that git would do a better job at re-applying to newer releases (i.e. merging from upstream master) than what patch(1) can do?

btown 11y ago
This makes me think that automatic rebasing and test running as a service would be an interesting product. Continuous integration of upstream changes into your possibly proprietary downstream fork (for features or ports), with Travis running each time.... You could avoid the problem of divergent forks!
- voltagex_ 11y ago
  I think you could probably make Travis do this itself - the script would be a bit gnarly though.
- viraptor 11y ago
  This is possibly the hardest version control problem I ever ran into. Especially in projects which have a large number of changes upstream (100+ commits daily), I've only seen bad and worse solutions. The bad one is trying to follow upstream on each commit, notifying you every time some patch either doesn't work or doesn't merge anymore so you have to fix it manually. This still doesn't stop the cases where the patch in itself works, but doesn't make sense in the project anymore (some code moved around, tests still pass, but the functionality is not reachable). You also need a fair bit of architecture to test each of your patches with on each upstream change. The worse solution is taking a few days off every time a bigger release is out and porting all patches. It saves on the continuous testing infrastructure, but takes unknown amount of time and you may discover some functionality simply cannot be migrated anymore. You're also likely to introduce many more bugs with rushed development. I've been through planning something like this on a number of projects before. It's a lot of effort and it should be avoided as much as possible. I think the product you describe could be actually a really good idea, but a lot of it would have to deal with as clever annotations as possible - what broke, when did it work the last time, who's responsible for porting, what functionality does it provide, is it critical/optional, etc.
kazinator 11y ago
That would require someone to read a man page or two. Which they clearly don't need to do because, nearly self-evident proof: they memorized the gnu diff and patch ones twenty years ago, QED.

asiekierka 11y ago

Spigot does this for another reason: thanks to someone making the arguably stupid choice of using GPLv3 for a project linking to (propiertary) Minecraft source code, CraftBukkit has been DMCA'd by one of the lead developers over Mojang taking over the project when the lead dev team quit and is now essentially illegal to redistribute.

belorn 11y ago
Was it ever legal to redistribute the proprietary Minecraft source code?