[Pulp-dev] Dev freeze

[Patrick Creech]

On Mon, 2018-11-05 at 14:58 -0500, David Davis wrote:
> I was looking at the release schedule page[0] and I saw that we define release terms like ‘beta’ and ‘release
> candidate’ but we don’t define what a ‘dev freeze’ means. I’d like to add the definition of ‘dev freeze' to our
> release schedule page since it sounds like there has been some confusion around what a ‘dev freeze’ is exactly.
> 
> The beta (as it’s currently defined on the release schedule page) is a freeze of all features or bugs except for
> regressions related to the release. Personally, I think a dev freeze should defined as a freeze of feature (or story)
> work but bug fixes are permitted. 

So, there are two unique items here.

The 'Dev freeze' intent is for all new code to stop, and any further commits are gated around if they a) are blocking
the build or b) the wilingness of the build team representative to permit the change to land, based on other risk
factors.

There is a series of events that take place from dev freeze to beta build, and each commit can reset this chain of
events, depending on where they the build is at in the process.

A feature freeze, similar to what is done over in katello/foreman, would necessitate another time box before dev freeze
for stabilization.

Most notably, the dev freeze intention was to prevent the last minute additions such that Build Team was not having to
turn a build around in 24 hours for a beta.  It wasn't as big of an issue in the merge-forward days, but now that we are
picking back, it has been proven stressful, especially for a .y release, and has delayed builds by days before.

What may be more productive, is a classification system for just what kind of fixes should at least be presented for
inclusion for a given dev freeze period.  Especially in the situation where I am not the build team representative doing
the build.