Please reply to general newsgroup ONLY, so that we can keep the discussion on one forum. Reply-to address is set, so you should be able to just hit Reply in your email client.
Chandler is currently on it's fourth milestone name scheme, and it looks like we might have a need to change it again for 'beta', and possibly again after that for '1.0'. I believe the naming schemes are different between Chandler and Cosmo. It would make sense to unify them because the current situation is causing confusion. We also have names for other stages of development, which also seem to differ between the projects. This is also causing confusion, for example not knowing just from the use of names how far away from release or milestone we are. So, to start with milestone schemes... Chandler currently is proceeding towards 0.7 Release (0.7alpha1, 0.7alpha2, ... 0.7alpha6, 0.7 Release). Actually there is also a question: should the 0.7 Release be called 0.7beta? Once Chandler reaches 0.7 Release, which we also call the Chandler Beta, are we going to continue with 0.8alpha1, ... or will that change to 0.8beta1? If it changes to beta, what happens when we hit our '1.0' release? What is Cosmo's milestone numbering scheme? Next are the terms alpha and beta. Chandler uses alpha to mark a product that is usable inside of OSAF. Beta is something we want the public to give a try; think "Google Beta". I believe Cosmo is using beta to mean feature complete; can you confirm? I believe we should unify what alpha and beta mean between the projects. Next item are the stages near a release. I'll describe what we use with Chandler, since I don't know anything about Cosmo's process yet. These have come a little fuzzy as of late, and I think we should re-clarify these. I should point out that all rules can be broken in exceptional situations (and have been broken in the past) ;) We have Feature Freeze, which means that no new features or functionality will be allowed to be checked in. We also require code reviews before checkin, and all checkins must address a bug that has been approved by Bug Council to be checked in (the bug is assigned to the milestone by the Bug Council, or in some cases even marked as blocking a release). All other stages beyond this point require Bug Council approval and code review. After that comes Code Freeze, which means we are ready to create a Release Candidate for testing. If testing passes, we have a Release. If it does not pass, we get new bugs filed, which get approved by Bug Council to be fixed even during the Code Freeze, and roll a new Release Candidate. We will soon need Internationalization, or Localization Freeze. Once this is in effect, no changes will be allowed which affect localization. Typically this would be somewhere between Feature Freeze and Code Freeze. We also have Documentation Freeze, which could perhaps be removed from the process. The idea with Documentation Freeze was that we could enter Code Freeze but still allow changes to comments, docstrings and the like. However, I am starting to think that it would simplify the process if we remove this step and state that everything must be completed by Code Freeze. Some people have also talked about Code Complete, perhaps meaning Code Freeze, but this is not clear to me. I think we should discourage the use of this term. We also sometimes talk about bugs that block a release. Bugzilla also has a special flag feature that can support this process. As the name implies, release blocker bugs will delay a release until they are fixed. -- Heikki Toivonen
signature.asc
Description: OpenPGP digital signature
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
