On 3/12/14, 12:09 PM, Mike Drob wrote:
- once a .0-SNAPSHOT branch has been created, every committer should follow
>some specified procedure before committing changes to it (I don't mean a
>voting procedure, more like soul-searching -- or perhaps a simple
>flowchart: Are you committing this change against a blocker or
>documentation-only ticket? No => Don't commit or merge it to this branch).
>
Soul searching is a very fuzzy concept that I am not comfortable with for
being used to drive releases. We've had an implicit (read: unwritten)
policy that only bug fixes can go into release branches, but many
developers (myself included) have stretched both the definition of bug and
the definition of fix. I'm completely on board with always making code
better, but it's also good to draw a line in the sand somewhere and
actually make releases.
I think I would actually prefer keeping things looser rather than having
to ask permission before making a fix (it just slows things down more).
That feels more in line with our CTR. I also don't think we've really
had a problem in this department before with changes being applied that
were then reverted (despite lines being stretched).
Also, even if the only bug-fixes in release branches wasn't written
down, I don't think there is any ambiguity or disagreement on following
that.
>
>Any thoughts or other suggestions on strategies to document?
>
Maybe we can add some release plan/manager basics to the bylaws?
"""A release plan consists of:
* a release manager
* a proposed version number
* a feature freeze date (bug fixes and documentation only)
* a code freeze date (documentation only)
* a planned rc vote date
Should any of these dates be missed, the release manager is responsible for
selecting new dates."""
A planned RC vote might be a bit aggressive. It's hard to judge whether
or not CI/RW tests will unearth some unknown bug. I like the other
items, though.
