> -----Original Message----- > From: Richard Purdie <[email protected]> > Sent: Friday, March 25, 2022 12:51 AM > To: Michael Halstead <[email protected]> > Cc: openembedded-architecture <openembedded- > [email protected]>; Lee, Chee Yang > <[email protected]>; Mittal, Anuj <[email protected]>; Steve > Sakoman <[email protected]>; Teoh, Jay Shen > <[email protected]>; Zhao Yi <[email protected]>; Michael > Opdenacker <[email protected]> > Subject: Re: QA and release process changes > > 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?
The artefacts are transfer to staging while prepare for test report. I think the tag is just for record at repo. - Request for Release approval for point release will have RELEASENOTES without known issue from "real hardware QA" and will not come with full testreport. - Release approval could potentially ahead of "real hardware QA " completion, in this case, any issue found during "real hardware QA " will add as known issue in RELEASENOTES later and will not block the release. - Prepare full testreport when " real hardware QA " completed. No need to send full testreport and updated RELEASENOTES for another round of review before release. is these correct ? > > Cheers, > > Richard >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1517): https://lists.openembedded.org/g/openembedded-architecture/message/1517 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]] -=-=-=-=-=-=-=-=-=-=-=-
