Please submit any publicly useful changes you make to packages upstream and don't carry the patches around in ltib for years. I am spending a month right now trying to forward port the lpc313x uboot changes up to current uboot. I've already brought the lpc313x changes up to the current kernel and need a newer uboot to support it. If those changes had been submitted upstream three years ago when they were written I wouldn't have to be doing this.
You really want changes submitted upstream. If you don't do it then you get locked into the version of the program that you patched. You may think that is saving you work by not having to hassle with the submission. And that appearance will be true until a security hole is found and patched in a latter version and your boss tells you that you have to apply the patch. Now you have a mess. The patch is against a latter version of the app that doesn't match your source code. To deal with the mess you either have to create your own private fork where you apply security patches to your old, patched code (this is a tower of cards that will fall as more patches accumulate) or you have to forward port the your initial patch. You could have avoided all of this by simply submitting the initial patch upstream. I've seen people change jobs rather than deal with messes created by private forks. Of course you can choose to ignore the security patches. Do you know how easy it is to hack something when you have the source code of the patch fixing the vulnerability? -- Jon Smirl [email protected] _______________________________________________ LTIB home page: http://ltib.org Ltib mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/ltib
