Sunday, April 13, 2014

"Drive-by-bugfixing" and why I might not bother anymore

I like to call this "drive-by-bugfixing" and this is how it usually happens:

  • I have a problem with e.g. xfce4-power-manager, which I'm unable to fix right now

  • I check out some random other package (let's call it "yerba-power-manager") to check if it can replace xfpm for me

  • I find it has a bug. Or two. Actually caused by broken openSUSE patches trying to implement new APIs

  • Because it is "an interesting problem", I fix it them just for fun

  • Later I find that I have no use for this package as (for unreated reasons), it does not fix any of my original problems



So far so good. Now I have a fixed package lying around in my home:seife buildservice repository. Trying to be a good cititzen, I submit it back to the original YERBA desktop project.
Can you imagine what happens next?
Correct! It gets rejected. Why? Because I did not mention all my patches in the changelog.

Come on guys. Policies etc. are all fine, but if you want people helping maintain your broken packages, then don't bullshit them with policy crap, period.
I had done the heavy lifting last sunday and fixed the bugs, now all that the desktop maintainer would have needed to do would have been to amend the changelog.

Well, I am not that interested in that particular desktop and its problems, so I just revoked the submitrequest and am done with it. I fixed XFPM instead :-)

And yes, I understand very well that such policies are a good thing to have, and necessary, and if I'm contributing to some subproject on a regular basis, then I of course make sure that I'm following these rules. On the other hand, it's really easy to discourage the occasional one-time contributor from helping out.

(Names changed to protect the guilty)

4 comments:

  1. I had the same experience. I made a three line fix (documentation improvement). And submitted it. Forward two weeks later i got an rejected, does not apply cleanly.

    I checked and found out the maintainer let it sit there all the time. Nothing happened in the projected. Then commited his own patch. After his change there naturally was a conflict. In the changelog. Easy to solve. But he did not care.

    Which meant i did not care either anymore. Fix revoked too.

    ReplyDelete
  2. Bruno Friedmann14 April, 2014 11:04

    Look like it appear also, on different project and packages. Even those who have related bugs entries. Are we really have a biggest problem than just those "incident"?

    ReplyDelete
  3. Actually not mentioning patches in the changelog will get submitrequests to factory rejected by the factory review team, so it is kind of rational for project maintainers to enforce that (at least if it's a package in factory).

    ReplyDelete
  4. That's all true -- but in the end will discourage occasional contributors.
    Before, the project maintainer would only have needed to add the patch name to the change log before forwarding to Factory.
    Now the patch is gone and the bug unfixed, so sooner or later he will have to fix the bug (something which was already done) and write a changelog entry.

    ReplyDelete