Today I had a question about having to fix patches against upstream changes because those patches were not included upstream yet is not very productive.
\n\nHowever, it is a prominent part of maintaining a code base. In the past 9 year, I and many others have been reworking a lot of CDK\ncode because of API changes and bug fixes in deeper parts of the CDK library. At least half of the work I have done for the CDK is doing this kind of\nfixing of downstream code. This is never trivial, and it is never productive. Well, depends somewhat on your definition of productivity.
\n\nWhether productive or not, it is just something that needs to happen. Additionally, it is not something you can prevent. I guess one can call this a\nfact of life. Doesn’t make it nice work. Not at all. And most of my frustration with the CDK library is the lack of documentation and unit testing,\nwhich makes such fixing of downstream code hard. This means that the person best suited to do this job, is the one who wrote the patch in the first place.\nThe person who made the comment I mentioned earlier is seeing this from very up close now.
\n\nI very much understand his feeling of being unproductive when updating patches; been there, done that. He (that I can disclose) is absolutely right. With\nall the quality assurance functionality I have set up in the past for the CDK, nicely integrated in Rajarshi’s\nNightly script, I hope to make it easier\nfor people to write proper maintainable patches. Often these reports are, however, again about doing tasks which make you feel unproductive. But I can\nassure you that writing such tools quality assurance tools, like the OpenJavaDocCheck \nI worked on this weekend, makes you feel even less productive.
\n\nSometimes making a library better maintainable, includes reworking the design. Almost always this take serious effort, and potentially introduce new\nbugs. At the same time, it always fixes a lot of older bugs and at the same time, of redesigned properly, makes it much easier to fix other bugs and\nallow more functionality to be implemented.
\n\nBut again, this requires rewriting of downstream patches too. And the one doing the redesign will always get comments about this requiring to make\nunproductive code updates downstream. I have seen this on several occasions in the CDK, such as my rewrite of the atom typing functionality in the\nCDK. (And don’t get any KDE4 developer started on that topic ;) Another fact of life, I guess.
", "summary": "Today I had a question about having to fix patches against upstream changes because those patches were not included upstream yet is not very productive.", "date_published": "2009-10-21T00:00:00+00:00", "date_modified": "2026-05-05T00:00:00+00:00", "authors": [ { "name": "Egon Willighagen", "url": "https://orcid.org/0000-0001-7542-0286" } ] } ] }