Hacker News new | past | comments | ask | show | jobs | submit login

So from what I understand, Google has a bunch of OpenSSL patches they use. They used to re-apply those patches to each new OpenSSL release, but now they're going to keep their own branch (BoringSSL) and pull and merge changes from OpenSSL?

What are the costs/benifits of one method over the other?




I think the costs and benefits are pretty much what you would expect. If your diff from upstream is small, then the tradeoff strongly favours rebasing against upstream and tracking it.

However, as the diff becomes larger, the tradeoff shifts. I think we passed that point a while back but, since we were going to switch models anyway, I took some time to clean up some bits of the code too.


I'm not so convinced about the tradeoff.

With your own patches you know exactly the reason and intent for each one - you wrote it! So you can rapidly figure out what to change to make them fit with the new release.

But in reverse you are going to have to grok every new change sent your way, and that it going to be a massive amount of work.

Some of it will be easy stuff: It's clear what they are doing, or it patches cleanly and you don't worry about it.

But then you'll run into more confusing changes and you're going to have a harder time. There is a human tendency to ignore that which you can not understand, and you'll have some of those, then a patch on top of them, and the final result is more work than you started with.


There is no singular "you". Google is a 50,000 person company. The 70 patches were likely written by dozens of different employees for different projects with different code bases. Some of authors may no longer even work at Google.


It's not a matter of trust:

http://users.skynet.be/bs939021/artikels/group%20versus%20in...

Are N+1 heads better then one? The group is better then the average head. Heads are worse then the best head.

I do not know however if Google makes reviewing the patches more time intensive then it should be, it all depends on the rate of progress, isn't it?


The trade off is that your patches are for things that you clearly care about, and do not want to lose. Having played this game several times, several ways, whichever branch the "patches" come from is lossy.


Fewer surprises. You don't wake up one day and discover that TLS heartbeats have appeared in your library as a result of previous upgrades. Every upstream change has to be reviewed because that's the only way it gets in. Also, local changes are much less likely to be lost as a result of merge conflicts.

The downside is that you may miss some upstream changes that you do care about.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: