Upgrade Scrumbugz instance

[julen]

Depends on:

• migrate bugzilla from extremadura to linode #2852 migrate bugzilla from extremadura to linode

Scrumbugz received lots of development during the last weeks and lots of things changed behind the scenes. Our scrumbugz instance needs to be upgraded in order to get the performance improvements and latest fixes.

The current deployment lives in our Linode instance and runs a SQLite DB backend. At least the DB backend needs to be changed. OTOH Linode could be exchanged by Heroku (in the free plan) to free up more resources.

Just note that Heroku doesn't guarantee 100% uptime in their free plan. Apart from that, since the Mozilla instance is running there and their usage is higher than ours, we wouldn't have any issues in terms of performance. Finally, since they rely on that platform, deployment and future upgrades should be straightforward as well.

In any of the scenarios (Linode or Heroku), we should first test the upgrade with a copy of our current data to assure we don't lose any valuable information.

[dupuy]

Something else that we may want to investigate when updating Scrumbugz is whether it is compatible with the new Bugzilla 4.0 workflow (as described here: http://bugzillaupdate.wordpress.com/2010/07/06/bugzilla-4-0-has-a-new-default-status-workflow/)

Essentially, the change is

NEW -> CONFIRMED
ASSIGNED -> IN_PROGRESS
REOPENED -> CONFIRMED
CLOSED -> VERIFIED

RESOLVED remains the same, as does UNCONFIRMED, if that latter status is enabled.

We might also want to add a status for tickets where we are waiting on some external action, commonly called NEEDINFO in some workflows. I also wonder if it may make sense to disable the CLOSED|VERIFIED state as that is only useful when you have a separate QA team (or role) where a second party actually goes and reconfirms that the supposed resolution actually does eliminate the bug.

The BZ workflow change would be a new ticket (that I won't create just yet), but there is a helpful script /var/www/sites/bugzilla/contrib/convert-workflow.pl that will convert a BZ instance to the new workflow states (historical data as well).

[dwaynebailey]

(In reply to Alexander Dupuy from BZ-IMPORT::comment #1)

Something else that we may want to investigate when updating Scrumbugz is
whether it is compatible with the new Bugzilla 4.0 workflow (as described
here:
http://bugzillaupdate.wordpress.com/2010/07/06/bugzilla-4-0-has-a-new-
default-status-workflow/)

Essentially, the change is

NEW -> CONFIRMED
ASSIGNED -> IN_PROGRESS
REOPENED -> CONFIRMED
CLOSED -> VERIFIED

RESOLVED remains the same, as does UNCONFIRMED, if that latter status is
enabled.

This is only an issue if we actually adopt that workflow right? And yeah I think it is a better one. It might be easily solved with a hack of scrumbugz

My comments below are based on your caveat that these would be a new ticket.

We might also want to add a status for tickets where we are waiting on some
external action, commonly called NEEDINFO in some workflows.

I'd prefer that it would be useful in our current state to at least put bugs that need input into an out of queue state.

I also wonder
if it may make sense to disable the CLOSED|VERIFIED state as that is only
useful when you have a separate QA team (or role) where a second party
actually goes and reconfirms that the supposed resolution actually does
eliminate the bug.

I'd leave it as it allows 3rd parties to verify our fix and indicate that it solves their issue.

The BZ workflow change would be a new ticket (that I won't create just yet),
but there is a helpful script
/var/www/sites/bugzilla/contrib/convert-workflow.pl that will convert a BZ
instance to the new workflow states (historical data as well).