Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

(as the author of the original post)

In theory, yes. And I never used to worry about this. But over time, in practice, it's been a bigger problem than I think you're giving credit to.

e.g. ...

"Even if you have 200 people submitting patches, the odds are that most of them fall into two categories: people fixing the same bug, and people working on completely different sections of code. Neither is a substantial problem to merge."

IME ... in practice, this is a HUGE problem. Because every one of those developers fixes the bug in a slightly different way.

The longer time goes on without the original Author fixing it, the worse it gets. And the cost to them - or anyone! - of sifting through the "100 variations on bug fix #123" becomes greater and greater.

Usually, you want to cherrypick individual lines and characters from 5-10 of the best "solutions" to the bug.

If you'd avoided the "100 alternative fixes", then those "improved" solutions would have been built on the "basic" solutions - and merging would be easy.

But because you've got to this massively-forked scenario, all of the patches have been written independently and incompatibly.



But because you've got to this massively-forked scenario

That may be true for the 0,0001% of projects that have so many contributors that they need dedicated release managers and such anyway.

The remaining 99,9999% projects are just grateful for github making contribution so easy that they're now receiving patches at all.


Not in practice. In practice, people base their work on the most recent work. You get maybe 4-5 versions of any given bug fix, max, proportionally to how easy it is to fix.




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

Search: