Release: branch then test, or test then branch?

[Andrew Geissler]

On Mon, Jun 10, 2019 at 10:22 AM Kurt Taylor <kurt.r.taylor at gmail.com> wrote:
>
> 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.

Yeah, my main concern was that we basically didn't do much as a
community. There was nothing to break us from our normal day
to day life (like a master freeze) so we all just kept developing (and
not focusing on tests or docs).  But the question is was there any
reason too? Is anyone using the tag? I know IBM is interested in
using this next tag as a potential base for a release so there may
be a bit more interest on our side with stability and security fix
back porting.

>
> 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.

Yeah, this seems like the best option in a lot of ways but I just
don't think the community is at a point where it could take a month
off from active development. I remember at one point we floated
something like 3 days for the freeze. That seems more realistic but
I still have doubts on whether we could coordinate well enough as
a community to get all maintainers to stop merging function for
ever that long. Would we ask for reverts if someone did merge
new function? Would we hold of the meta-* bump merge if it looked
like a feature vs. a fix? Would we make Brad be the enforcer since
he does the majority of the meta- merging?

>
> 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.

My vote is still for what we did with 2.6, branch on freeze. When we do
the branch we should tag master with a 2.8.0-dev to get rid of the
ambiguity we had last time.

>
> Kurt Taylor (krtaylor)