First, we have a group of developers ... all are individuals, some may build a team ... The sources they'll get from the main website or the read-only Software-Assessment repository [D], thats a mirror branch from the production system. They can add an individual developers branch [A] on that repository too, not mixed with the other branches.

Developers send their patches:

thru their developers branch [A],

through github developer branches(needs further documentation),

by email (preferable as diff),

by an attachment in the bug-tracker

by an attached diff (preferred) or updated/replacement file (deprecated) in the bug-tracker (BenBE)

thru other channels

to the Software-Assessment team.

Status of bug in bugtracker switch to "Fix available"

Step 2: First SA review, transfer to testserver repository

Involved parties: Software-Assessors, Software-Assessment team

Documentation: Bugtracker

Software-Assessment team reviews the code. At least 2 Software Assessors have to approve the patch and have to document this in the bugtracker.

Step 3: Test scenario deployment

The Software-Assement team reviews the patches and order them by priority and relevance to add the patch to the test-branch [B] in the repository.

There will be a test entry page in the wiki (Software Testers Portal), showing the current patches that are under testing, with the links to the bugtracker or the overview descriptions. The Software-Assessment team checks also the requirements against the possible addtl. tasks that needs to be performed to prepare the testserver to be ready for testers.

Documentation includes required infos to the software testers:

Bug number and link to the bugtracker

short description of the bug / patch

short description of patch area (what functionality will be changed by the patch)

requirements to test the patch (for example: you need several accounts with client- and server-certs, and one test must pe performed with an account having Support-Engineer privileges)

Step 4: Software testing

The testers now starts testing on the testserver with reporting into the related bugtracker entry. The test team is a group of software testers, build from developers and ordinary users from the community that share their experience about used testing tools and scripts. Everyone single report of a successfull test cycle or problem report is welcome. At least two

Status of bug in bugtracker switch to "Needs review" if patch testing is complete (tested by at least 2 software testers)

Step 5: Second SA review, transfer to production

Involved parties: Software-Assessors, (Sysadmins)

Documentation: Bugtracker, Git

Action items:

A Software-Assessor reviews the patch (2nd review)

A Software-Assessor reviews bugtracker documentation

reviewed by 2 Software-Assessors

tested by at least 2 software testers

Software-Assessors bundle the tested patches to a release candidate in the release candidate branch [C] of the repository. At this step, there can be an addtl. test phase for the installation procedure and recovery procedure. This will be documented also in the bugtracker.

If once bundled, a Software-Assessor send / transfer the release candidate bundle to the critical sysadmin team with further instructions how to install the patch and a informations for a fallback strategy. This will be documented also in the bugtracker. Delivery of the diff patch will be send also via cacert-devel mailing list.

Send by signed mail to critical with cc to cacert-devel; CC skipped if private information have to be transferred, with public details disclosed ASAP.

Status of bug in bugtracker switched to "ready to deploy"

Remark: Second review can be made anytime between step 2 First Review and testing is running

Step 6: Implementing to production

Involved parties: Sysadmins

Exceptional strategy: Sysadmins, Software-Assessor, Arbitrator

Documentation: message to cacert-systemlog at lists.cacert.org

Sysadmin team installs the release candidate on the production system. If there are some problems, they follow the fallback strategy.

Documentation of install procedure: in the bugtracker

The changes will be automatically synchronized to the repository within the production system. Sysadmin team triggers a push replication of that repository to the mirror repository on the Software-Assessment repository [C] (see also cacert-systemlog [cvs.cacert.org checkin notification] messages)

Exception:

If the fallback strategy doesn't solve the problem, and the sysadmin team cannot solve the problem alone, they can get assistance from the Software-Assessment team by giving one named Software-Assessor (related to the discussion - here the name 'Application Engineer' can be set) access to the production system thru a controlled remote session. This needs to be arbitrated later on (documentation of this process thru an arbitration case).

Step 7: post work

Involved parties: Software-Assessor, Test team

Documentation: Wiki page, Bugtracker

Software-Assessment team verifys the installation of the release candidate by comparing the 2 repository branches [C] (release candidate) and production-system-mirror [D]. and document the result in the bugtracker.

Test team updates the software testers portal and transfers the fixed patch to a test finished subpage

Adhoc SQL queries

Adhoc SQL queries are probably triggered thru an arbitration process. Documentation will be written within the arbitration case protocol

The adhoc sql queries will be prepared/reviewed (and) tested by the Software-Assessment team in above step 5 and have to be transfered to the sysadmins. The sysadmin team executes the sql query against the production system.

Emergency Patches

Involved parties: (Developer), Software-Assessor, Sysadmin

Documentation: Wiki page, Bugtracker

Emergency patches follows the path described in the "Software Updates, Software patches" section, except the bundling hasn't to wait for the running test patches. The emergency patch has to be tested individualy bundled individualy, and transfered as an emergency patch to the sysadmins on the production system. The changes have to be incorporated from the mirror repository [D] later on to the testsystem.

OS Updates

OS Updates can be tested on the testservers. With the installation procedure the updates can be applied onto the production system by the Critical sysadmins

As Testserver system environment should be as comparable to the production system environment, the testing of OS updates on the testserver follows the Software Update Cycle management, first test updates on a testserver, then apply on the production system.