We’ve updated our online XML-RPC client to include:
- Many Trac templates – you can now easily test the Trac XML-RPC interface.
- Basic Auth support – for those APIs (Trac) that require basic authentication you can now supply the username and password.
We’ve updated our online XML-RPC client to include:
Email is often the #1 focus for advice on how to be more productive. Tactics like “don’t process email first thing” or “batch your email twice a day” are commonplace on the web.
Paul Graham wrote the seminal article Maker’s Schedule, Manager’s Schedule back in 2009 where he discussed why meetings destroy productivity for makers since it takes so long for a maker to achieve the productive “flow” state. The concept behind this is sound and why I think so many give the email advice they do.
However, the advice often doesn’t distinguish between makers and managers. Ignoring your email (or at least batching it) is sound advice for makers, but it is suicide for managers.
My job as a manager is communication. How can I do my job well if I ignore one of the primary modes of communication? That is like telling a salesperson to ignore the phone.
Now I will be the first to admit that there is lots of non-productive email so the trick is not to ignore all your email, but to triage it. There are several systems out there such as David Allen’s Getting Things Done which you can use for the actual tactics, but the point is you need to have some kind of system.
My morning routine is in direct opposition to most email advice. I spend the first hour or 2 of every day responding to email. Why? Because other people are waiting on decisions or information that I provide. Without my input they can’t proceed and that impedes their productivity and my goal it to get them working again as soon as possible.
Now I know some of you are thinking that I shouldn’t be the bottleneck or that I am micromanaging my team. I will just just point out that my team members have lots of latitude to make decisions, but occasionally my input is needed. This probably represents 1% of my emails.
The next bulk of the emails (40-50%) are informational so that I know how the business/project is going. These emails may spawn other emails as I keep various stakeholders in the loop.
Then there is a small number of “educational” emails which are typically mailing lists I’ve subscribed to. These get processed last and are typically skimmed. If there is something interesting or worth more attention I flag them and move on.
The rest of it is junk and I just delete it.
Does this process burn up my best and most productive hours of the day? Nope, because I’m not a maker.
Helga is a Python chat bot. Full documentation can be found at http://helga.readthedocs.org.
The Bugzilla plugin allows Helga to respond to Bugzilla ticket numbers in IRC and print information about the tickets. For example:
03:14 <devzing> bz 123 03:14 <helgabot> devzing might be talking about https://app.devzing.com/demo/bugzilla/show_bug.cgi?id=123 [[TestProduct] Ticketing Box City selector]
Find out more at https://github.com/ktdreyer/helga-bugzilla
my $client = BZ::Client->new( url => $url, user => $user, password => $password, autologin => 0 ); $client->login(); $ids = [ 69, 101 ]; my $bugs = BZ::Client::Bug->get( $client, $ids );
pip install python-bugzilla
This package provides two bits:
This was originally written specifically for Red Hat’s Bugzilla instance and is used heavily at Red Hat and in Fedora, but it should still be generically useful.
import bugzilla bz = bugzilla.Bugzilla(url="https://bugzilla.kernel.org") print bz.getbug(1)
Bugzilla 5.0 is right around the corner and honestly we’re a little excited.
Bugzilla 5.0rc2 is available now if you like to live on the bleeding edge. There aren’t any changes expected between now and when 5.0 is officially released in a couple of weeks. If you are interested in upgrading just let support know and we’ll take care of it.
Don’t have Bugzilla? Support can add it to your account at any time.
Don’t have an account? Get started in under a minute.
For everyone else we will follow our typical upgrade process. We will test 5.0 ourselves and monitor any issues other people in the community are running into. Once we are confident that 5.0 is stable enough we will send out an announcement about when the upgrade will happen and give you the option to opt out.
Here are some highlights of what you have to look forward to:
This release has major improvements in the WebServices interface. One big addition is a new REST-like endpoint alongside the existing XML-RPC and JSON-RPC endpoints. This will allow clients to access Bugzilla data using standard HTTP calls for easy development.
Several methods have been added and existing ones improved to allow returning data that was not available before such as Group.get. Bug.search is now as full featured as the Advanced Query UI allowing for the same searches to be executed. Attachment data such as flags and other metadata can now be updated through the API.
Users can add tags, visible to other users, to bug comments. This gives the users the ability to thread conversations, mark comments as spam, identify important comments, etc. Users can hide comments that contain specific tags if desired. The tag input field also supports autocompletion so commonly used tags can be selected. Administrators can make specifically tagged comments be automatically hidden from view.
There is now a “Preview” mode when creating a new comment that allows you to see how the comment will look before committing to the database. This will let you see the results of the “autolinkification” of bug references and links.
Bugs can now have multiple aliases assigned to them. Before each bug could only have a single value. Also, aliases are now visible in the browser’s title bar.
You can now choose to not receive any mail at all about a particular bug, even if you continue to have a role on that bug (e.g. reporter).
Some useful searches have been added to the Bugzilla home page.
Quicksearch now allows for use of comparison operators such as !=, >=, >, <, etc., in addition to substring searches.
The “Blocks” and “Depends On” values can now be displayed as columns in a bug list.
There are now INTEGER and DATE custom field types.
Bugzilla is now HTML5 compliant.
When a site administrator creates a new user, an email is sent to the user.
Unfortunately the “Make Bugzilla Pretty” effort stalled and was replaced by incorporating the theme used by bugzilla.mozilla.org which also unfortunatly did not make it into 5.0, but is rescheduled to 6.0.
Another exploit has been discovered which affects many Linux servers. The moniker is GHOST.
During a code audit performed internally at Qualys, we discovered a
buffer overflow in the __nss_hostname_digits_dots() function of the GNU
C Library (glibc). This bug is reachable both locally and remotely via
the gethostbyname*() functions, so we decided to analyze it — and its
impact — thoroughly, and named this vulnerability “GHOST”.
As of yesterday all our servers were patched with the newest glibc version.
A new security attack (dubbed the POODLE attack) makes continued use of SSLv3 dangerous. So effective immediately, we are dropping support for SSLv3. Browser users will likely see minimal-to-no impact. If you are having an issue please try a newer version of your browser.
Extremely old browsers (specifically IE 6 users on Windows XP) will no longer be able to connect to devZing pages. We performed a traffic analysis that shows this would have affected no customers in the last 90 days.
This integration will allow you to use GetHub commit comments to update bugs
This will cause any commit comments to be added to bugs references by the comment. E.g. the commit comment “This fixes bug 123” will cause “This fixes bug 123” to be added as a comment to bug 123.
You must configure both Github and devZing to make this work.
To configure GitHub click Settings when viewing your repository
Click Webhooks & Services
Click Add Webhook
Fill in the Payload URL:
Content type can be either application/json or application/x-www-form-urlencoded
Feel free to add a secret as we will be supporting this soon.
Make sure you have selected “Just the push event” as other event types will be ignored.
Then click Add Webhook to save your webhook.
Next log into your devZing account and click “Manage Global Settings”
In the “Github Integration” section select a Bugzilla user that will be used for the integration.
In daily use just include the keyword “bug” next to the Bugzilla defect ID you want to update in the commit message. Remember that the Github webhooks aren’t executed until you push your changes and that there can be several commits in a single push. Every commit message in a push will be evaluated so you can update 1 or 100 bugs in a single push.