Freezes

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As far as stages go, I think that we should just use the term Freeze  
and have different kinds.

On the Cosmo side, right now I think that having a Feature Freeze and  
a Code Freeze will be sufficient for where we are.   If we need more  
Freezes, then I'd like to see us borrow the labels and meanings from  
Chandler.

The only area that I am unsure about is with respect to the hosted  
service, and whether or not we need a level of freeze to indicate  
that Jared can test and verify a cosmo build as being suitable for  
installation on the production service instance.

Ted

On Aug 29, 2006, at 11:41 AM, Heikki Toivonen wrote:

> 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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFE9NWqYCjW/J06/U8RAqlGAJ0UwMBQEr4fJMsReuxO0FCORybRPwCfcLw/
MjEojFdD4vApNQTeC8zNbXY=
=KKBG
-----END PGP SIGNATURE-----
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general