** Description changed:

  [Impact]
  The launchpad-service-status script indicates whether or not Launchpad is 
available.
  lpltk clients use this tool to determine whether they will fail if they 
attempt to run.
  
  One of the things the tool does to achieve this is to check the
  Launchpad blog for planned outages.  However, if there are no planned
  outages listed in the feed, the tool fails due to undefined values.
  
  [Development Fix]
  The 2.x development series includes a fix that checks the results of the blog 
screenscraping before attempting to use it.  This 2.0 branch is uploaded to 
quantal.
  
  [Stable Fix]
  The same fix applies on the 1.x stable series, which is being proposed for 
precise.
  
  Note that with this change we're bumping the number from 0.5 to 1.0, to
- indicate the package is now released and considered stable.  There are
- no other changes besides this bug fix.
+ indicate the package is now released and considered stable.  See package
+ changelog for other changes (mainly fixes to unreported bugs) included
+ in this release.
  
  [Test Case]
  1.  Install package
  2.  launchpad-service-status
  
  Broken Behavior:
  $ launchpad-service-status
  Traceback (most recent call last):
-   File "/usr/local/bin/launchpad-service-status", line 50, in <module>
-     if datetime.now() > outage_start and datetime.now() < outage_end:
+   File "/usr/local/bin/launchpad-service-status", line 50, in <module>
+     if datetime.now() > outage_start and datetime.now() < outage_end:
  TypeError: can't compare datetime.datetime to NoneType
  
  Fixed Behavior:
- $ ./scripts/launchpad-service-status 
+ $ ./scripts/launchpad-service-status
  UP READWRITE
  
  [Regression Potential]
- None really.  This just adds a check for None values before using them.
+ This particular change just adds a check for None values before using them, 
it's unlikely to cause a regression.
+ 
+ There are some other changes included in 1.0, all of which are believed
+ safe but the quantity of code changed means regressions are always
+ possible.  I feel this is a negligible risk though, because two of the
+ bug fixes included in 1.0 address API changes in Launchpad that occurred
+ a few months ago, and scripts written using the current (0.5) lpltk
+ simply won't work.
+ 
+ As per UDS decisions, we're trying to shift into a more normal release
+ process.  However to date, most users of lpltk that I'm aware of install
+ and run from bzr due to problems such as those mentioned above.  We're
+ hoping by being more aggressive at getting those kinds of fixes through
+ SRU, we can gain better maintenance updates going so people don't need
+ to run from bzr.  So although this release contains some extra changes,
+ I think they're needed, and going forward we're going to be more
+ cherrypicky.
  
  [Original Report]
  /usr/bin/launchpad-service-status
  Traceback (most recent call last):
    File "/usr/bin/launchpad-service-status", line 50, in <module>
      if datetime.now() > outage_start and datetime.now() < outage_end:
  TypeError: can't compare datetime.datetime to NoneType
  
  A quick look at the code shows that this tool is based on screen scrapping
  the launchpad notification feed
  
  http://blog.launchpad.net/category/notifications/feed
  
  and is coming up empty.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/988312

Title:
  launchpad-service-status can't compare datetime.datetime to NoneType

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-launchpadlib-toolkit/+bug/988312/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to