On Thu, 2022-03-24 at 09:29 -0700, Michael Halstead wrote:

On Wed, Mar 23, 2022 at 4:58 AM Richard Purdie
<richard.purdie@...> wrote:

Hi All,

There are a few different discussions I'd like to pull together and talk
about
some QA and release process changes.

Firstly, we've just made some changes to the docs build process. This is now
deriving the version information from the git tags in the docs repository.
This
means as long as the tags are present, the versioned docs should appear
correctly on the website.

This means changes to the release process but they should be simplifications
and
make things easier and simpler for everyone involved. Simply tagging a point
release should enable all the right things to happen. A new release series
should just need changes to set_versions.py in master and then the correct
things should also "just happen". If there are any questions or issues let
me
know.

The second thing we've been discussing is streamlining the release process
where
it makes sense to, particularly around point releases. Since we started the
current processes the autobuilder has massively improved in test coverage
and
we'd like to be more dynamic with point releases.

Experience tells us that the majority of blocking issues in a point release
are
found on the autobuilder and that if the autobuilder build is green, the
release
is likely going to go ahead. The "real hardware" testing QA does is
extremely
valuable and important but in general hasn't been finding issues that block
releases.

As such we'd propose that for point releases:

* we proceed to release after builds pass as green on the autobuilder
  or only show well known intermittent failures.
* 'real hardware' QA takes place alongside that release process
* the test results of that extra QA are merged into the release artefacts
later 
  as additional test results

Right now we tag the test results in yocto-testresults-contrib on release day.
In the future we will release right away then when the full test results are
available tag them and update the RELEASENOTES. Is that correct?

I'm not sure we need to tag that repository, I think it was mainly there to
allow transfer of the results over to the release artefacts?

Cheers,

Richard