Release: branch then test, or test then branch?

Kurt Taylor kurt.r.taylor at gmail.com
Tue Jun 11 01:22:01 AEST 2019


All,

Before the last release (2.6) the release planning working group
decided to branch on the freeze date and then continue development on
master, while testing, documentation, and release notes happened in
parallel. It worked reasonably well, but there were some glitches. For
this upcoming release (2.7) we are reconsidering this decision.

There have been concerns raised on this model (please elaborate if you
have an issue). I believe that the test and security working groups
have identified requirements to change this, but I would like to have
specific reasons. And, I was not totally happy with the platform
verification testing/reporting or feature documentation.

The alternative, and my slight favorite, is to branch at release, not
at freeze. This enables ALL (developers, testers, document-ers) to
focus on the release specifically, instead of continuing to develop
code. The downside is that it does stop new functionality patchsets
merging in master for a 3-4 week period. We could shorten the freeze
window if all were focused on polishing the release, however. This is
not the popular option since folks just want to write code, not test
or write documentation, but I believe it can make higher quality
releases.

Here is a drawing that may help explain what we are considering for 2.7.

https://github.com/openbmc/openbmc/issues/3555

Please comment here, comment on the above issue in github, or come to
a release planning meeting if you want to learn more or join in on the
decision process.

Kurt Taylor (krtaylor)


More information about the openbmc mailing list