[PATCH 0/1] rant: cleanups are cleanups
Felipe Contreras <[email protected]> Thu, 18 Aug 2022 00:27:27 -0500
| Newsgroups | gmane.comp.desktop.xfce.devel.version4 |
|---|---|
| Message-ID | <[email protected]> |
I spent several days programming improvements for xfce4-panel, I sent the improvements through the usual channels, and nothing happened. I wait **three** years to get a response, and after several years the response is: "what currently exists is good". OK. I wanted to implement a "binary time" [1] clock, and I can understand if the maintainer doesn't want to add that feature, but I coded dozens of cleanups to get to that point. The cleanup patches are logically independent from the new feature. They could be merged **regardless** of the new feature. The maintainer eventually sees the light and realizes: "I see that the first patches seem sane and justified" [2], reopens the ticket, and then... Immediately backtracks and demands a justification for every single commit. OK, I can spend several days programming some improvements, wait three years, and spend several more days reprogramming those improvements, no problem. While reworking those same patches I did several years go, I go through several rounds of review. "Move this patch to the beginning" OK. "Move that patch to the end" OK. At one point the maintainer says I should drop a patch that converts an array of integers. I send a new version of the branch where that patch is at the end therefore it's clear why it makes sense. Now the maintainer agrees it makes sense and asks me to include the patch sooner, therefore going back in time two revisions. After dozens of versions of multiple branches and many arguments, most of the patches end up being merged. That is good. But a few patches are not merged. Why not? Because they missed their chance. What does that even mean? I have already spent several days working on these patches over the span of more than three years, and because of that I came up with ideas to improve the existing code. This will help whomever decides to work on this code in the future. This is the diffstat of the cleanups I did that are already merged: plugins/clock/clock-binary.c | 284 +++++++++++------------------------ 1 file changed, 91 insertions(+), 193 deletions(-) This is the diffstat of the cleanups still missing: plugins/clock/clock-binary.c | 89 +++++++++++++----------------------- 1 file changed, 31 insertions(+), 58 deletions(-) The behavior of the code is **exactly** the same, but it's simpler. Xfce does not precisely have an overabundance of developers. So to reject patches that will make the life of new developers easier does not make a lot of sense. And to shit on new contributors who are offering cleanup patches out of their own free time with comments like [3]: No sorry, I didn't drop them in !94 (closed) to merge them now. Does not help the project move forward. Cleanups are cleanups. Cheers. [1] https://en.wikipedia.org/wiki/Binary_clock#Binary_time [2] https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/235#note_53175 [3] https://gitlab.xfce.org/xfce/xfce4-panel/-/merge_requests/95 Felipe Contreras (1): clock: binary: consolidate algorithms plugins/clock/clock-binary.c | 104 +++++++++++++---------------------- 1 file changed, 38 insertions(+), 66 deletions(-) -- 2.37.2.351.g9bf691b78c.dirty _______________________________________________ Xfce4-dev mailing list [email protected] https://mail.xfce.org/mailman/listinfo/xfce4-dev