On Thu, 2022-03-24 at 09:29 -0700, Michael Halstead wrote: > > > On Wed, Mar 23, 2022 at 4:58 AM Richard Purdie > <[email protected]> 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1516): https://lists.openembedded.org/g/openembedded-architecture/message/1516 Mute This Topic: https://lists.openembedded.org/mt/89973619/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
