[PATCH 0/1] rant: cleanups are cleanups
Felipe Contreras
felipe.contreras at gmail.com
Thu Aug 18 07:27:27 CEST 2022
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
More information about the Xfce4-dev
mailing list