[pkg-apparmor] UDD notifications script

intrigeri intrigeri at debian.org
Wed Feb 18 17:45:48 UTC 2015


hi,

intrigeri wrote (18 Feb 2015 16:02:46 GMT) :
>> Would you, Holger and/or intrigeri, care to review this?
>> https://github.com/u451f/usertag-notifications/blob/master/udd.py

> I'll do a code review later today.

Here we go (disclaimer: I'm not a good Python programmer, so I'll have
to nitpick on minor style things and design patterns ;)

Meta: I'm taking this as an opportunity to share with you about
programming in general, because 1. the code apparently works and is
good enough for the task at hand, even without any of the changes I'm
suggesting below! and 2. you and I will soon have more programming
things to do and share on another project, so let's start now to learn
what each of us likes/dislikes/etc., so I'll go into many details.

Feel free to tell me "patches are welcome" on 

* this script needs a shebang, otherwise I've no idea if it's Python 2
  or 3. (isn't it Python 3, btw? if not, why? :)

* s/GPLv=3/GPLv3/

* the "filename" variable could have a less generic name, e.g.
  state_filename; similarly, I would rename the "user" variable to
  "team_email_address", and s/sender/email_sender/ and
  s/receiver/email_receiver/

* s/bdourl/bdo_url/ and s/usertagurl/usertag_url/, for
  readability, perhaps?

* I see:
    # connect to UDD and get all bugs for a certain user
    def uddConnect():
  but it seems that this function only connects to UDD, and the bugs
  retrieval is done elsewhere, so perhaps update the comment?

* Shouldn't we exit with a non-zero error code from errorHandler?
  but then I realize that this function is used both for fatal errors,
  and for mere warnings, so I don't know. Also, errorHandler always
  says "Could not process UDD query", while 2 of its 3 callers have
  nothing to do with UDD queries, which indicates that perhaps this
  function's scope has been extended beyond its initial design, up to
  a point when it needs to be rethought a bit.

* It's a bit confusing that compareState runs saveState, which means
  it doesn't do (only) what its name and documentation say. Same for
  it sending email.

* Generally, I think the functions in this program do too much, rely
  too much on global state, and have too many side effects, which
  makes them harder to (automatically) test in isolation. For example:

  - saveState should take state_filename as a parameter, instead of
    relying on global variables; bugList should take the user as
    a parameter; etc.
  - it would be good to turn compareState into a pure function;
    I guess it would take (old_buglist, new_buglist) and return a list
    of changes, that we would pass to another function whose sole
    purpose would be to send notifications
  - I could go on and on, but you got the idea, right? :)

* Maybe the parameters we pass to the smtplib.SMTP constructor could
  be part of the configuration on top of the script?

* In compareState, maybe rename "data" to "olddata", since we have
  "newdata" already. It would make the algo easier to grasp, at least
  for me.

* compareState seems to only report back about added usertags, but not
  about removed usertags. Should be easy enough to do the latter
  too, no?

* In compareState, apparently we're saving state even in the case when
  we've discarded the new data set as invalid, and decided it's not
  worth comparing it to the old data set. Is it on purpose?
  This wouldn't happen if the errorHandler that was called with "Could
  not retrieve new data" did exit the script.

And, to end with: I'm happy this script exists, runs fine, and does
its job! Congrats :)

Cheers!
-- 
intrigeri



More information about the pkg-apparmor-team mailing list