Forum OpenACS Improvement Proposals (TIPs): Tip #50: (Approved) Freeze HEAD between feature complete date and beginning of alpha testing

Collapse
1: Tip #50: (Approved) Freeze HEAD between feature complete date and beginning of alpha testing
Posted by Joel Aufrecht on 02/24/04 07:23 PM

Proposal

After we reach our nominal Feature Complete Date, core HEAD is frozen to new features until all Feature Complete criteria are met (the criteria are basically that HEAD is not broken). At this point, a new minor branch is created and core HEAD is re-opened to normal commit rules.

I am calling for a full vote immediately (rather than the fast-track with veto process). OCT members, please vote either Approved or Disapproved.

If this TIP does not obtain a 2/3 majority Approved within 2 weeks, I will assume status quo remains in effect. I interpret status quo as: branch core upon reaching the feature freeze date; the branch is immediately feature-frozen.

Reasons

This is fundamentally about the balance of work between "maintainers" and "developers," for several reasons:

If we branch immediately on declared code complete, bug fixing will happen on the branch and must then be merged or fixed in two places.

Branching on code complete may encourage developers to continue new feature development at the expense of bug fixing; this is inefficient for the project as a whole because many unfixed bugs are blockers for other people, including end users, translators, and other developers.

Having a HEAD freeze period will help break the tragedy of the commons we are experiencing with getting core bugs fixed. As long as the feature complete criteria are reasonable (everything is committed; no pri 1 bugs in core or standard packages; HEAD installs and passes smoke tests), this essentially means that we are asking developers to volunteer up to a few days every 3-6 months to focus on fixing critical bugs, either their own or unowned bugs.

The 5.0.0 release experienced delays after code complete when most core developers were busy on other projects. This proposal would help address that by providing more predictability for core developers to know and help determine in advance when then they are being asked to volunteer time.

In my very limited research, this appears to be similar to the FreeBSD and Mozilla release processes.

Note that the freeze would affect only core packages, not applications or contrib.

Reasons Against

  • Feature freeze is easier to enforce if we branch on freeze, because default commits won't go to the branch
  • This means that there are times when there is no public place to commit new work on core modules.
  • The process is simpler
  • Enforcing a feature freeze requires work to communicate and do cvs commit inspection and rollback.

Implementation

  • Decision is communicated in forums
  • post-commit notice is added to cvs, so that all core commits see a warning notice.
  • Release management team is given approval to roll back new feature work.

References

Release plans for 5.1 (feature freeze 22 Feb!)
Collapse
2: Re: Tip #50: (Proposed) Freeze HEAD between feature complete date and beginning of alpha testing (response to 1)
Posted by Jeff Davis on 02/25/04 09:44 AM
I interpret status quo as: branch core upon reaching the feature freeze date; the branch is immediately feature-frozen.
I think defering creating the branch until someone wants to commit something which should not be in the release is the status quo as it is how it has been handled to date and was I think the consensus when we discussed it last week.

In any case, I am willing to try anything once so I would certainly approve of trying this methodology.

Collapse
4: Re: Tip #50: (Proposed) Freeze HEAD between feature complete date and beginning of alpha testing (response to 1)
Posted by Malte Sussdorff on 02/25/04 10:51 AM
I follow Jeff, let's try it out. If it fails, we can still come up with a new TIP improving this one.

Approved.

Collapse
8: Re: Tip #50: (Proposed) Freeze HEAD between feature complete date and beginning of alpha testing (response to 1)
Posted by Lars Pind on 02/25/04 05:38 PM
Approved.

Let's go for it.