As part of the Quality Assurance effort for bookloupe, proposed fixes are published in the testing repository for testing. Where fixes involve changes to the code, alpha versions are released and Microsoft Windows binaries provided.
Resources and other links:
Proposed fixes included in 2.0.69 for testing:
Bookloupe bugs go through a number of stages, which are explained here.
When bugs are first entered by an ordinary user, then they have a status of UNCONFIRMED. This status is used for bugs that need attention by QA before they are ready for developer attention. Normally this will mean that QA will set the priority and adjust the severity. A decision will also be taken on whether the report represents an actual bookloupe bug or a feature request that QA believed would improve bookoupe. Once QA is happy that the report is ready for developer action, then the status is set to NEW.
A bugzilla search for bookloupe bugs needing triage (requires registration).
Once bugs have been triaged, they enter a pool waiting for a developer to get around to working on them. At this point, the status is set to ASSIGNED and the "assigned to" field is set to the developer in question.
A bugzilla search for bookloupe bugs waiting in the development pool (requires registration).
Once a developer has finished working on a bug and has a proposed fix, they set the status to RESOLVED (eg., to RESOLVED FIXED) to indicate that QA need to sign off on (verify) the action taken.
A bugzilla search for bookloupe bugs currently in development (requires registration).
Once a bug has been resolved, QA will test the proposed fix and either re-open the bug if more work is needed or set the status to VERIFIED if it is accepted.
A bugzilla search for bookloupe bugs in testing (requires registration).
Once a bug has been verified, the fix needs to be pushed to the stable repository ready for release. Once this is completed, the status can finally be set to CLOSED.
A bugzilla search for bookloupe bugs waiting to be pushed (requires registration).