Development/Hard Hacks

Introduction
This page is dedicated to collecting "Hard Hacks" for our more experienced developers to take on as soon as they go from the proposed state to the confirmed state (see process section). These hacks are meant to not last long in the "hard hack" stage, instead they are meant to quickly be assigned to a developer -- or more likely willingly accepted by a developer -- during conference calls. In most cases a hard hack should be assigned to a developer in less than a month and a patch should be committed in no longer than another month. If the list of hard hacks gets too long without developers being assigned, the process of accepting proposed hard hacks as official hard hacks stops until the back log is handled. This list is meant to be a temporary solution until we are able to correctly prioritize bugs in Bugzilla.

What is a hard hack?
Hard hacks should meet the below requirements:
 * 1) Be relatively annoying for a significant amount of people
 * 2) Be relatively difficult to solve and/or track down
 * 3) Crashes/data loss are good candidates but not necessary
 * 4) Backtraces should be done on proposed hard hacks before they become accepted hard hacks
 * 5) Enhancement requests should NOT be on the list

Process
The process is quite simple, everyone is welcome to nominate a hard hack as a proposed hard hack by adding the Bug # as well as your name to the table below, this list will then be the basis of our bi-weekly QA discussion about hard hacks, where we then will collectively bring an appropriate number of hacks from the proposed section to the confirmed section. Please do not put bugs immediately in the accepted hard hacks table, this only makes the process messy and unreliable.

Joining QA Call
As mentioned above the QA conference call is made bi-weekly, usually on a Friday at 1400 GMT. Please join the QA mailing list where you'll receive an email bi-weekly detailing the date/time and agenda for the next meeting.