2.1.2 PRR

Estimatation of QA hours

Considering the work done and the length of the cycle compared to 2.1.1, it's possibly near 600. This is purely a guess as many people haven't responded with this information

Deployment testing

More attention needs to be given to this. Building a clean install and a final test of the upgrade path from different releases (ie 2.1 to 2.1.2 or 2.1.1. to 2.1.2) need to be done. Fisrt and foremost, we need to find resources to do this. Megan will send out a request for resources via the newsletter.

Given the current resources pool, QA servers may need to keep backups of the data to roll back to. Scripts that populate sites with data are also an option if data retension isn't possible.

Conversion scripts need more testing across different platform combinations. In the past these have typically been thrown together at the last minute.

Adequate test coverage

Automation of functional tests is becoming more and more critical. Ari expressed interest in this and JMeter was recommended. Need to identify more resources that can get involved in this. One way to start this would be to identify components where automation is critical - for instance, T/Q or GB. Another is to script tests for any bugs being verified. In this process we'll start to get more and more coverage.

Performing bug verification closer to when the bug was actually verified would keep up from being in a "scramble" mode in the end and allow for more time to review the general functionality just prior to the release. There are two issues to think about 1) Interpretation by creator 2) Interpretation by developer. Testing closer to the time work is actually be done would minimize any gaps between the two. This would require expanding the nightly servers. At one point it was thought that the QA servers would revert to a nightly build and then slow when the community went into the release phase. The timing of the maintenance branches hasn't alloted much time for this

QA server Network

Still looking toward expanding this pool. It was suggested that when Rutgers have the available resources, they are interested. U of Capetown is also a good candidate.

Samigo

There have been a lot of changes. Some institutions are having trouble updating Samigo for 2.1.2. This tool is a great candidate for functional scripts

Communication about release

Many people didn't seem to have a good grasp at what was going to be included in the release. We need to give a better idea of this. For the 2.2 release there is the project mgmt confluence site, but not everyone is updating. Perhaps better clarification could be given after integration week

Some discussion was centered around understanding how the community requirements are being incorporated into the 2.2 release. If resources are available and the component leads have the time available, this work will be incorporated.