Re: Suggestion: Changes to release process, release from branch

"Andreas K. Huettel" <[email protected]> writes:
> * With the hard freeze two weeks before nominal/last possible release
> date, the release branch is made, and the master branch is re-opened
> for development.

I don't feel strongly about this, but let me add some reasons to not do
this:

* Easier to make changes in the release that aren't reflected back to
  master (and visa-versa)

* Developers and contributors focus on master and the release branch
  gets ignored

* Testing on the branch doesn't help master as much

* Important patches may not get copied to the branch in time

* Developers don't get a break from developing ;-)  (not that they want
  it, because we're all overachievers, but it's still a good thing ;)

* If a patch is needed on the release branch, it still has to go through
  the get-approved-on-master process first, and if master has diverged
  from the release, this becomes more difficult.

It's been my experience, here and on other projects, that release
branches are where code goes to die.  The users use it, but the
developers are elsewhere, because elsewhere is more fun.  IMHO the
longer we can keep the developers focused on a release, the better.

I suppose we should dig up the archives from the discussion about moving
to the current model, and see what problems were were trying to solve
back then.