Goal :
. to write down our release process, and propose it to core devs team, and then to adopt it.
. To imagine which tool should be used to do our release debug parties (forum?dedicated web site?)


Ideas
1/ a few people like local support team members and choosen well known debug experts, received betas, this at each step of development process if it is possible
After corrections were made, an RC is released.
2/ This RC is posted officialy at xoops.org. If needed RC2/RC3/ect. are released. Devs ask community to get involved in release protocol "Are you ok with this version to be a final. Be responsible for."
3/ test per developments phases
4/ have some time to test. We should set a minimum time duration between last RC and final, and between RC
5/ to document/explain changes and awaited impacts/side effects (what we should test first because part was heavy changed",please, so we can test with more efficiency.

this QA team forum is used to make a clear list, with ideas provided by community in this public thread

https://xoops.org/modules/newbb/viewtopic.php?topic_id=40697&start=0#forumpost178299
Please refer to this last one to give your ideas/feedbacks

marco
QA Team

Here is a small summary (not finished yet)
I've tried to collapse all our ideas.Thanks for your brainstorming.
Comments awaited (it's still a quick summary draft, I have to change some wording and make it clearer.
marco



1/ Developer must perform internal "test run" before announcing anything

2/ Testing Team
- a few people like local support team members (1)
- choosen well known debug experts (2)
(1) To ensure language issues also deal with too - sometimes easy to overlook things that may be "rendered" differently in other languages
(2) include users of a capable ability... but not newcomers who have not had chance to "get their hands dirty" with Xoops...
Could be the same team as module testing...

They received betas
After corrections were made, an RC is released.

3/ Test are made per developments phases
This at each step of development process if it is possible
Core devs document/explain changes and awaited impacts/side effects (what we should test first because part was heavy changed",please, so we can test with more efficiency.

4/ This RC is posted officialy at xoops.org. If needed RC2/RC3/ect. are released.
Devs ask community to get involved in release protocol "Are you ok with this version to be a final. Be responsible for. please make final tests and notice bugs devs and testing team have not detected"

5/ have some time to test.
We should set a minimum time duration between last RC and final, and between RC (time frame for RC release to stable)

6/ No public release until team was totally happy with it
A certain number of positive test reports should be required prior to deciding that the release is ok for everyone to use, regardless of how long that takes.
+
no public release until an RC (minimum) was published @xoops.org so that end users (community) make final tests
"unstable" releases be clearly labeled as such, so people are aware that they shouldn't blindly upgrade their production sites.

A dedicated test team who know what they are doing would enable the core team to release an RC in the confidence that it *does* install properly and function properly - provided the system requirements are met and the HTTP/PHP server and database server are correctly configured.
Users can then debug the RC, but at least the core team will know that an 'I get a blank screen' post is a system config problem, not a XOOPS problem.

7/ Message to end users
In each news announcement, we should remember to users
- install/upgrade process : this one should be standardized (i think it already is).
- make personnal tests before use in production environment :" anything new is unstable". test it locally
- process for feedbacks

8/ Time for announcment
Devs should be there the day after announcments to help people if new bugs are detected and make patch.

7/ Test on several platform
IIS/Win XP
Apache/WinXP
Unix/Linux
Most of the error reporting and problems seem to comme from upgrading. Since the core devs probably don't test it with the many different setups we all have, it is near impossible for them to find all problems.
It would be important that each can list up the particulars of their installs, server platforms of course, but modules also and any other special hacks they use


Tools
1/ discussion should be private until a mature status is agreed on - as public discussion too easily disintegrates into off-topic chat.
2/ Release could be posted on a separate page, with a big red notice at the top stating that they haven't been fully tested yet.
The announcements could still be posted here, but the extra step of having to go somewhere else to download might be adequate.
4/ Rough aims and methods for such a team... (they can be finalised at a later stage)
5/ tool for tester :I will (marco) make such a list, dedicated to core, inspired from Checklist4ModDev (QA tool for module developers)
6/ Consice definition of what would be considered a good bug report

example --> "cookie cutter" template is targeted to the inexperienced XOOPS user
Quote:
+theme and modules.

Volonteers (to be checked)
jdseymour
kaotik
Lance_
SoccerDad
rowdie
Chappy
Teibaz
JMorris
dap997

We need testers on each area : core and core themes