Plone Quality Assurance Team

Plone 3.3 had about 6 months of prereleases. Very little testing and feedback coming in, very late. Shouting "Please test!" did not help. If companies were using prereleases and it was working fine you only heard it when you explicitly asked it.

Several browser tests are missing, like for collections, which is why they were broken for two releases. Also Selenium tests.

Hanno was looking at all the bugs, reassigning them. Very useful, but too much for one single person.

Another task would be specifically testing just before or after a release.

Having data about how many times the versions.cfg of a release candidate is downloaded would be handy. Getting no negative feedback but also no positive feedback is not good. Are there no problems or is no-one using it.

Having a list of things to do before a release is handy.

Testing a release candidate during the Plone TuneUps is good. Make some noise about that.

InstallFest: get people to try out the installers and be available on irc for support.

http://pypi.python.org/pypi/mr.ripley: replay the requests of a live site on a staging server.

Idea: button "Ready for Plone 4" for third party products on plone.org?

Buildbots for the most popular third party products?

Important things to do:

1. Triaging bugs.
2. Get people to test releases.

Tell Joanna when a new release is coming up so we could use testers in the Plone TuneUp.

Get a list of which things to change when a new release is there, like also the topic of the #plone irc channel.

Test coverage runs for packages are interesting as well.