Repository navigation
The update nightmare in the stable-v1.6 branch #25
Description
Can someone explain me the updates in the stable-v1.6 branch?
The HEAD commit in stable-v1.6 is floating. We are using this as the source of our packages. Please, do incremental changes only or do not mark your code as stable (put it to the stable branch)! Thank you.
Commit da8cb04 disappeared like commit 47b436a .
@plbossart , @xiulipan - comments?
Activity
perexg commentedon Nov 30, 2020
Can I use the commit cbdec69 as the final binary v1.6 release? Or not?
plbossart commentedon Nov 30, 2020
@lgirdwood @mwasko this one is for you to address.
xiulipan commentedon Dec 1, 2020
@perexg I think we also have rc binary in this branch. To avoid big git size, we always rebase the branch.
@lgirdwood Should we use tag for the release or branch?
perexg commentedon Dec 1, 2020
The development should be moved to some other place or just do incremental changes. I have packages which refer to the detached commits da8cb04 and 47b436a which is really not optimal. I don't even know, if commit cbdec69 is stable or not. Please, clarify.
Unfortunately, the new hardware requires those signed firmware files, so the faster incremental changes are really preferred to have something for test / update before users are disappointed.
Thank you.
lgirdwood commentedon Dec 1, 2020
@perexg apologies - there was some issues and delays fixing an issue that could have meant software changes outside of the FW/kernel between rc3 and now. This is something we need to improve upon.
The issue is now resolved and validation should complete for v1.6 final today at which point @mwasko can sign and release.
Fwiw, we are looking to overhaul the binary release infrastructure for v1.7 (due end January) and @marc-hb will be leading this effort. @marc-hb please align with @perexg on any requested requirements/improvements.
Add built tgl rt715-rt711-rt1308 tplg file
marc-hb commentedon Dec 1, 2020
Binaries or not, force-pushing a branch with
stablein the name is really not OK. Let's just not do that again.git has unfortunately no way to advertise volatile branches, just project-specific naming conventions. If we really need to force-push throw-away binaries we must at least use another branch with something "volatile-looking" in the name, say a
v1.6-tempbranch for instance.More widely shared Release Candidates must obviously never be deleted.
I'm well aware using git to release binaries is a major performance mistake but @xiulipan does
sof-binperformance really matter? Is there some automation repeatedly cloning this that would be affected?linux-firmwareis full of binaries. No one pretends it's fast but I have not heard anyone complaining it's unusable either.If yes git performance of
sof-binis a serious concern for some reason then an entiresof-bin-temprepo can provide a very simple and short term solution.mwasko commentedon Dec 2, 2020
I agree with that. Once we announce the release and create stable branch or any other target release branch we should stick to it and only add commits on top of that if necessary.
perexg commentedon Dec 2, 2020
Any update on this? I would like to package the final 1.6 ASAP. Thank you.
Also, the release scheme should be described in main https://github.com/thesofproject/sof-bin/blob/master/README.md file.
perexg commentedon Dec 7, 2020
Ping.
xiulipan commentedon Dec 8, 2020
@perexg sorry about the mess, I double confirmed the repo and find more issue with the v1.6-rc3 binaries.
PS: we are now using PR mode for the stable-branch update.
@lgirdwood Please help to check #26
@lgirdwood @mengdonglin Any idea about the release scheme
lgirdwood commentedon Dec 9, 2020
@xiulipan #26 merged. The readme.md should contain a link to the latest binaries and some instructions on how to manually install them (these instruction should support copy and paste into a users terminal)..
@perexg apologies, one of our validation platforms and engineers has been impacted by a local lockdown and this has impacted our progress.
cinerea0 commentedon Dec 10, 2020
To clarify, will future releases be tagged in their respective stable branches?
lgirdwood commentedon Dec 10, 2020
@cinerea0 yes - future releases will be tagged - the rebase was a mistake.
lgirdwood commentedon Dec 18, 2020
@perexg, @cinerea0 now released v1.6.1 - tagged as v1.6.1. Apologies, this has been slow to validate due to local lockdown restrictions for some of the validation team.
perexg commentedon Jan 3, 2021
It seems that the Jasper Lake firmware is missing in v1.6.1 (b77c851). It is present in v1.6 branch (faa5bdc).
mengdonglin commentedon Jan 4, 2021
@perexg @lgirdwood Jasper Lake firmware signed by Intel production key has not been verified on any product device yet, so we didn't include it in v1.6.1. Shall we only publish a Jasper Lake firmware signed by the community key?
lgirdwood commentedon Jan 4, 2021
@mengdonglin please do include in the release - I have confidence with CI and validation that it should be fine for JSL (based on the same IP in other platforms). We should still do the full validation when local Covid restrictions allow and can log/fix bugs in the mean time.
xiulipan commentedon Jan 5, 2021
@mengdonglin @lgirdwood add public signed JSL binary with #29
lgirdwood commentedon Jan 5, 2021
@marc-hb fyi we will need a
make checkrule similar to linux firmwares rule which must be run prior to publishing a release. This should check for missing files.perexg commentedon Jan 25, 2021
Closing. All my reported issues were resolved.