December Downtime, Revised

Please be advised that there will be an extended system outage starting December 10 03:00 UTC (Dec 9 22:00 New York, Dec 10 14:00 Sydney).

This downtime will last approximately 10 hours.

During this time all equipment will be moved to a new data center. Because this move is an entire data center and not just devZing equipment we do not have any flexibility with regard to the timing of this downtime.

As a result of this move our IP addresses will be changing.

If you have a custom domain name please make sure you are using a CNAME record pointing to app.devzing.com rather than an A record pointing to our IP address.

December Downtime

This downtime has been rescheduled by 1 week. See this post for more info.

Please be advised that there will be an extended system outage starting December 3 03:00 UTC (Dec 2 22:00 New York, Dec 3 14:00 Sydney).

This downtime will last approximately 10 hours.

During this time all equipment will be moved to a new data center. Because this move is an entire data center and not just devZing equipment we do not have any flexibility with regard to the timing of this downtime.

As a result of this move our IP addresses will be changing.

If you have a custom domain name please make sure you are using a CNAME record pointing to app.devzing.com rather than an A record pointing to our IP address.

Extended System Downtime Nov 25, 2011

This downtime has been rescheduled by 2 weeks. See this post for more info.

Please be advised that there will be an extended system outage starting November 26 03:00 UTC (Nov 25 22:00 New York, Nov 26 14:00 Sydney).

This downtime will last approximately 10 hours.

During this time all equipment will be moved to a new data center. Because this move is an entire data center and not just devZing equipment we do not have any flexibility with regard to the timing of this downtime.

As a result of this move our IP addresses will be changing.

If you have a custom domain name please make sure you are using a CNAME record pointing to app.devzing.com rather than an A record pointing to our IP address.

Bugzilla: File a Bug by Email

Want a fast and easy way to file a bug?

Now you can file bugs simply by sending an email.

Bugzilla, hosted by devZing, has a feature that allows a user to send an email to an email address. Bugzilla reads the email and automatically puts the bug into tracking phase.

Interested? Here’s how it works…

Set up

Administrators: Start with an email address your users can send their defects and comments to. Log into your devZing account (http://devzing.com/login) and click the Manage Global Settings link and scroll down to the Email Bugs section.

Enter the information about your email account.

The port number depends on how the mail server is set up.

Typical port assignment:

POP3=110, IMAP=143, Secure IMAP (IMAP4-SSL)=585, IMAP4 over SSL (IMAPS)=993, Secure POP3 (SSL-POP)=995.

If you don’t know the value for one of the fields check with your System Administrator. (Or check your email provider’s help documents.)

Helpful hint: Use the devZing history section to track errors once users start sending emails.

Sending the Emails

Users must follow a few guidelines when they send emails to the administrator. These are necessary steps to enable Bugzilla to receive and correctly read the emails.

First get the email address from your Bugzilla administrator. Your email address must be the same address you use to login to Bugzilla.

Subject Line: Put a summary of the bug as your subject line.

Follow this guide for writing the email contents…

Any fields (see below) must be specified before your bug description.

Here is a list of all the different fields you can specify in your email:

Field Name

Description

Must Match?*

Required?

@product

The name of the product the bug is being filed against.

Yes

Yes

@component

The name of a component in the product above.

Yes

Yes

@version

A version of the product above; the version the bug was found in.

Yes

Yes

@summary

A brief description of the bug being filed. If you specify this field it will override the summary you specified in your email subject line.

No

No

@platform

What type of hardware the bug was experienced on.

Yes

Maybe**

@severity

How severe the bug is.

Yes

Maybe**

@op_sys

The operating system the bug was discovered on.

Yes

Maybe**

@priority

What order the bug will be fixed in by the developer, compared to the developer’s other bugs.

Yes

Maybe**

@alias

A brief alias for the bug that can be used instead of a bug number when accessing this bug. Must be unique in all of this Bugzilla.

No

No

@assigned_to

A user to assign this bug to, if you don’t want it to be assigned to the component owner.

Yes

No

@qa_contact

If this installation has QA Contacts enabled, you can set the QA Contact here if you don’t want to use the component’s default QA Contact.

Yes

No

@status

The status that this bug should start out as. Note that only certain statuses can be set on bug creation.

Yes

No

@target_milestone

A valid target milestone for this product.

Yes

No

@cc

A comma separated list of users to CC on this bug.

Yes

No

@id

Specifies the bug number to modify. See “Modifying an Existing Bug” below for more information.

Yes

No

@removecc

A comma separated list of users to remove from the CC list on this bug. Note you can only use this field if you are updating an existing bug.

Yes

No

* The value must match exactly one of the names defined in your Bugzilla for this field.
** It is possible that your Bugzilla administrator has provided a default value for this field.

In addition to the above parameters, if your installation has any custom fields, you can set them just by passing in the name of the field and its value as a string.

The values for the fields can be split across multiple lines, but note that a newline will be parsed as a single space, for the value. So, for example:

@summary This is a very long
description

Will be parsed as “This is a very long description”.

Note that signatures must start with ‘– ‘, the standard signature border.

Modifying an Existing Bug

Bugzilla determines what bug you want to modify in one of two ways:

  • Your subject starts with [Bug 123456] — then it modifies bug 123456.
  • You include @id 123456 in the first lines of the email.

If you do both, @id takes precedence.

You send your email in the same format as for creating a bug, except that you only specify the fields you want to change. If the very first non-blank line of the email doesn’t begin with@, then it will be assumed that you are only adding a comment to the bug.

Note that when updating a bug, the Subject header is ignored, except for getting the bug ID. If you want to change the bug’s summary, you have to specify @summary as one of the fields to change.

Please remember not to include any extra text in your emails, as that text will also be added as a comment. This includes any text that your email client automatically quoted and included, if this is a reply to another email.

Errors

If your request cannot be completed for any reason, Bugzilla will send an email back to you. If your request succeeds, Bugzilla will not send you anything.

If any part of your request fails, all of it will fail. No partial changes will happen.

Caution

The script does not do any validation that the user is who they say they are. That is, it accepts any ‘From’ address, as long as it’s a valid Bugzilla account. So make sure that your MTA validates that the message is actually coming from who it says it’s coming from, and only allow access to the inbound email system from people you trust.

Unvired MantisBT client for BlackBerry

Our friends at unvired have a great native BlackBerry client for MantisBT that works out of the box with our MantisBT hosting package.

With the unvired client you can access all project and bug information including attachments. Seamless offline viewing and data refresh. Works even without internet connectivity and will sync automatically whenever connectivity is detected. Fantastic UI with easily accessible dashboards and information at the click of a button.

Our MantisBT hosting plan is pre-configured to work with the BlackBerry client, no additional configuration required.

Bugzilla Tip: Deleting An Attachment

How do you delete an attachment on a Bugzilla entry? Good question!

Attachments in Bugzilla are used to help document a bug. Whether the document you’ve attached was the wrong screenshot, or was attached to the wrong bug record, was uploaded in error (a picture of you and friends out for some Thai food), or perhaps something an employee maliciously wanted to put in to get back at you, you have the wrong document. Time to delete. What do you do?

The answer is just a bit different for the administrator than for the non-administrator.

Administrators

Administrators may easily delete a bug attachment.

First give yourself the ability to delete attachments.

From the Main Page… Administration -> Parameters. Select “Attachments” on the left-hand table.

Scroll down just a bit to “allow_attachment_deletion”.

Turn this feature “on”.

Find the bug with the wayward attachment and click the Details link on the right side of the attachment. Below the Comment box you will see a link to Delete the attachment. Click the link (you may enter a reason for deletion if you want) and click Yes, delete. Your attachment is gone.

Non-Administrators

As a non-administrator you can’t really delete an attachment; all you can do is mark it “Obsolete.” This really only hides the attachment unless you click the Show Obsolete button, but it does keep it from being front and center.

Open the bug. (Go to the “Bug List” page, find the “Summary” of the bug and click the link. This opens the bug.)

Information about the attachment appears at the bottom of the bug page. Click the details link next to the attachment.

Then click edit details to show the obsolete check box.

Select the “Obsolete” check box.

Click Submit to save your changes.

Remember devZing for Bugzilla hosting

Bugzilla Tip: Watch Another User

Did you know you can track the emails another Bugzilla user receives?

If you are part of a team which uses Bugzilla, and (for instance) another Bugzilla user on your team goes on a vacation, you can see the emails Bugzilla sends to that team member.. You can “watch” other user’s Bug Mail.

Bugzilla’s “User Watching” feature controls this.

In order to watch others, do this…

Preferences -> Email Preferences

Scroll down to the “User Watching” section.

In the User Watching section you see a field with all user email addresses. Select the email addresses of the users you want to watch. (Use Ctrl-left click to select more than one user email address.) Click the Submit Changes button. Another field appears which displays the users you now watch.

You will receive a copy of all the email those users are sent. Any event that would trigger an email to them triggers an email to you.

Note that the user you are watching can see that you are watching them.

How do I “unwatch” a user?

In the “User Watching” section, look for “You are watching everyone in the following list:”. The field below this lists the users you watch. Select the users you no longer want to watch. (Ctrl-left click to select more than one.) Check “Remove selected users from my watch list” then click “Submit Changes”.

Subversion tip: Update works, but commit fails

You use devZing Subversion hosting for your project. The time comes to sync your file(s) and a problem arises when you do so. I mean, the update worked. But it fails to actually commit. The error message “Authorization failed” appears. What is going on? How can there be an authorization failure?

Well, the problem is simple and the solution is simple, too.

Here’s the problem: Subversion has a quirk. It lies in the commit process.

When you create a working copy, you can accidentally put in a technically incorrect URL and it still works. The checkout allows the case of the characters to not match the “official” URL. Because the update command is case in-sensitive, whereas the commit command is case sensitive, Subversion allows the error. For example, your original (and “official”) URL may be “svn://svn.devzing.com/Me/MyRepo1“. But when you enter the URL in the checkout command, the command which creates the working copy, you accidentally enter everything lowercase. You put in “svn://svn.devzing.com/me/myrepo1“. That’s easy enough to do.

But the commit doesn’t recognize this URL and rejects it with an “Authorization failed” message. It only accepts the exact original.

So check your original repository URL.

 

 

Make sure everything is exactly as it shows in the URL column.

The solution is simple indeed. Just check the URL of your working copy.

Subversion Tip: Fix Missing Date and Author in Svn Log

If you are trying to use the svn log command and the output is missing the author and date fields like the following example:

c:working> svn log
------------------------------------------------------------------------
r8 | (no author) | (no date) | 1 line
------------------------------------------------------------------------
r7 | (no author) | (no date) | 1 line
------------------------------------------------------------------------
r6 | (no author) | (no date) | 1 line
------------------------------------------------------------------------
r5 | (no author) | (no date) | 1 line
------------------------------------------------------------------------
r4 | (no author) | (no date) | 1 line
------------------------------------------------------------------------
r3 | (no author) | (no date) | 1 line
------------------------------------------------------------------------
r2 | (no author) | (no date) | 1 line
------------------------------------------------------------------------
r1 | (no author) | (no date) | 1 line
------------------------------------------------------------------------

More than likely your Anonomous Access is set to Read.

Change this to None to prevent this problem.

If you are using a client like TortoiseSVN you may need to clear any cached logs.

In TortoiseSVN go to the settings screen and look for the Cached Repositories node. Then select and delete the repository you just fixed.

Be sure and check out our subversion hosting service.