Jeff Quast

Python Developer

Week of Feb 04, 2015

It has been a bit of a while since I last updated the OSS contributions I've made, nearly two months. I worked very hard to release x/84 which took a toll on my energy. I had a PR which I listed in my previous post accepted by paramiko. x/84 made the rounds on hacker news and reddit and even made its way into pycoder's weekly. I suggested it to pycoder's weekly last release and it was ignored. I think "being voted up on reddit" is their only indicator of what makes it in, which is too bad, I had to finally make a reddit account to make such post and I don't plan to use it ever again. pychina's weekly, If I translate correctly, has some mention that somebody is working to use x/84 for Tsinghua bbs, which if I'm not mistaken may be SMTH?

Anyway, here's my last few weeks in review, maybe missing a few:

  • after seven months, a fix for sh.py was finally accepted, PR #189.
  • as well as a suggested fix for sh.py regarding using tcgetattr from the slave, rather than the master end of a pty on the "Unix 98's", Issue #143.
  • added functional tests to the xmodem project. PR #8.
  • A pretty serious bug in xmodem crc checksum failures discovered by integration tests to achieve more coverage. PR #11.
  • Sometimes github issues are nothing more than support. I don't know how people end up with issues like these but I was glad to be able to help resolve it without much difficulty.
  • More fixes to prospector, fixes regressions introduced in a new version, PR #85.
  • after adding FreeBSD to my build infrastructure, caught pexpect bug Issue #180. Although a primary contributor, I do not have the pypi access to release the fix, so it remains open at this time.
  • Sometimes improving a README is all a project like EtherTerm needs to get a little help, PR #4

Looking at the PR for sh.py finally being accepted a half year later, I am reminded of Python issue #20664 which, although patch provided, has gone unresolved. I'm not sure what to do about such things, I guess we just wait for more users say "me too" to bring it to attention again.

Lessons learned:

  • after much reflection over the holidays, I believe ego to be the number one most destructive force in a software engineering team (open source or corporate). I may do a post about that after some more thought.
  • Support issues disguised and argued as bug reports are incredibly time consuming. It upsets users and drains maintainers from otherwise fruitful work. I have no incentive to contribute to Stack Overflow, but I may change documentation to suggest users to request support there.
  • Several documentation spelling, grammar, or technical errors were discovered but unreported because the offending project is not on Github. The "drive by" costs of signing up for a mailing list to email a patch or find and/or reset a bitbucket password and learn enough mercurial again just isn't worth it. For example, I found a bug in the stty(1) manpage of FreeBSD regarding imaxcanon: I won't be creating a bugzilla account for a 1-line diff anytime soon.