On Thu, Oct 11, 2012 at 06:38:57PM -0400, Ehsan Akhgari wrote: > On 2012-10-11 6:36 PM, Mike Hommey wrote: > >On Thu, Oct 11, 2012 at 06:14:51PM -0400, Ted Mielczarek wrote: > >>On Thu, Oct 11, 2012 at 4:20 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> > >>wrote: > >>>What I really don't want us to do is to prohibit people from fixing things > >>>in the imported code. That is the absolute worst situation we can face > >>>with > >>>a given piece of code, as we already have learned painfully. > >> > >>This should absolutely be at the discretion of the maintainer of the > >>imported code in our tree. From personal experience, allowing local > >>changes to land in Breakpad before they are landed upstream has caused > >>huge headaches. Our in-tree copy of Breakpad was nearly 2 years > >>out-of-date because of a few large patches that landed in support of > >>OOP work and were difficult to upstream. > > > >Same experience with jemalloc, which is why the rule is to have things > >applied upstream first. > > What is the nature of this problem? Is it the difficulty to reapply > the patches when pulling new code from upstream? Note that I'm > mostly talking about fixing small problems in our copy, not doing > major architectural changes.
Experience shows that adding patches to our copies of third party libraries lead to, at least: - long-time forks - undocumented patches (no corresponding patch file in the tree to reapply = fun to handle upgrades, or broken upgrades if unnoticed) - outdated patches (a .patch exists but doesn't correspond to what is in the tree = most likely broken upgrades) - unapplied patches after an upgrade (= broken upgrade) I have seen multiple iterations of each of the above. This is not a theoretical problem. And some even happened with things that are much less third-party than most third-party code we have in the tree: nspr and nss. Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
