It now has been several weeks since RC3 has been released and Johan did some explanation in hit blog post “Is Joomla! 1.5 RC really a release candidate?“. People who have been to the Swedisch Joomla!day or those who have taken a look at my presentation of that Joomla!day will have noticed I have given and explanation what we mean with “It’s done when it’s done”. I am fully aware this is a very confusing phrase and certainly gives no clear insight on when Joomla! 1.5 will be finished, so let me try to clear this one up.

Within the team we talk about the Joomla! 1.5 finalisation strategy. A fancy word on how we try to manage to get a stable version out. So what does that finalisation strategy look like?

• The main purpose of the Release Candidate is to improve stability. Each new release must strive to be more stable than the previous one. Issues that arise from patches to seriously flaws or security issues that counter this but we work on minimizing this so these will be exceptional circumstances.
• Goals are to be set so that we can measure performance, and be accountable to each other and the community. Stable should be declared when all priority 1 (P1) and 2 (P2) artifacts are resolved and all translations have been completed.
• Every week (or bi-weekly) we review the Tracker with the team to discuss if the trunk is ready for either Stable or the next Release Candidate. Goals for the following week(s) should be set (for example, to resolve all P2 artifacts) based on the resources available. The number of each artifact type, including a break-up of new and existing artifacts, should be recorded at each meeting to be able to measure progress.
• The release cycles are set by these meetings and there is no limit to the Release Candidates subject to the prior conditions being met (that stability is improving, etc), nor is there a set time frame. If a Release Candidate can go out every week or every four weeks as long as stability is improving.

With this simple strategy in place it is better to say “It’s done when all priority artifacts 1+2 are done”. This of course is not completely true, because there are some issues we really want to be 100% before we declare stable. I will try to blog on these issues openly so everyone is informed. If you want to follow discussion close I suggest you take a look at the public mailing-list we have. If you want to follow progression on the tracker, just take a look at the Joomla! tracker.

So what is the plan for the upcoming week(s)? First we scan the forum, and move all issues left there to the tracker. We are preparing for the bug squeezing events, and to get people acquainted with our tools and our way of working I will try to blog on specific topics like “How to use the tracker”, “How to create a patch” etc. As mentioned earlier on, you can help out reaching our goals, the bug squeezing events are just a start…

It now has been several weeks since RC3 has been released and Johan did some explanation in hit blog post “Is Joomla! 1.5 RC really a release candidate?“. People who have been to the Swedisch Joomla!day or those who have taken a look at my presentation of that Joomla!day will have noticed I have given and explanation what we mean with “It’s done when it’s done”. I am fully aware this is a very confusing phrase and certainly gives no clear insight on when Joomla! 1.5 will be finished, so let me try to clear this one up.

Within the team we talk about the Joomla! 1.5 finalisation strategy. A fancy word on how we try to manage to get a stable version out. So what does that finalisation strategy look like?

• The main purpose of the Release Candidate is to improve stability. Each new release must strive to be more stable than the previous one. Issues that arise from patches to seriously flaws or security issues that counter this but we work on minimizing this so these will be exceptional circumstances.
• Goals are to be set so that we can measure performance, and be accountable to each other and the community. Stable should be declared when all priority 1 (P1) and 2 (P2) artifacts are resolved and all translations have been completed.
• Every week (or bi-weekly) we review the Tracker with the team to discuss if the trunk is ready for either Stable or the next Release Candidate. Goals for the following week(s) should be set (for example, to resolve all P2 artifacts) based on the resources available. The number of each artifact type, including a break-up of new and existing artifacts, should be recorded at each meeting to be able to measure progress.
• The release cycles are set by these meetings and there is no limit to the Release Candidates subject to the prior conditions being met (that stability is improving, etc), nor is there a set time frame. If a Release Candidate can go out every week or every four weeks as long as stability is improving.

With this simple strategy in place it is better to say “It’s done when all priority artifacts 1+2 are done”. This of course is not completely true, because there are some issues we really want to be 100% before we declare stable. I will try to blog on these issues openly so everyone is informed. If you want to follow discussion close I suggest you take a look at the public mailing-list we have. If you want to follow progression on the tracker, just take a look at the Joomla! tracker.

So what is the plan for the upcoming week(s)? First we scan the forum, and move all issues left there to the tracker. We are preparing for the bug squeezing events, and to get people acquainted with our tools and our way of working I will try to blog on specific topics like “How to use the tracker”, “How to create a patch” etc. As mentioned earlier on, you can help out reaching our goals, the bug squeezing events are just a start…

Read original post at source site... http://www.joomla.org/component/option,com_jd-wp/Itemid,105/p,446/.