Hi everybody,
it's that time of year again: we should look into cutting a release. Not because there's anything noteworthy that we should bring out (although there certainly is), but because we have a 6-monthly cadence of giving our tree a new number and pushing out tarballs and press releases.
I plan to do the release on or shortly after May 11, and this announcement is in accordance to the process detailed on https://doc.coreboot.org/releases/checklist.html, so we're at the "~2 weeks prior to release" point right now.
As such, there are a number of things I ask of you (all of you subscribed to the list, but since you're reading this mail, yes, I mean you, personally!):
1. If you have anything big that you want to get in before the release, it's on you to maintain the changes responsibly and responsively so that it all works out in time. I'll gladly help coordinate things but I'm not interested in last-minute heroics, so get in touch with me ASAP.
2. Please try to postpone riskier refactorings and the like until after the release (unless they're ready to land in the next few days), so that people have a solid foundation to test their hardware on. Which gets us to the next point:
3. Please test your coreboot-supported gear if you can, report and/or fix issues, and upload fresh reports to the board-status repo. While we have no quality requirement for releases - they're _really_ only about giving the tree a new number, a release is a good opportunity to verify that what we have in the tree is still functional, with only limited work required to pin-point new issues (bisections since 4.11 should take 12 steps or less at this time).
4. Please check the preliminary release notes in Documentation/releases/coreboot-4.12-relnotes.md and add whatever happened since 4.11 that you think is noteworthy. If in doubt, push a change to gerrit and see what your fellow developers think about it.
Thanks, Patrick Georgi
Hi Patrick,
Your help and dedication is much appreciated!
As we (FB and its partners) successfully finished bring-up of coreboot on CooperLake-SP based 1 socket platform, we are shifting our focus to exclusively on Cooperlake-SP based platfroms, away from using Skylake-SP based TiogaPass as the feature development vehicle.
This timing works well with the planned coreboot release. We have a number of SKX-SP platform related changes in the pipeline, we will try our best to work with the community to get them merged, then we will run a test pass, and we could report the status to the community (such as document what works and what further works are needed in Documentation/mainboard).
Many features (in particular smbios and BMC interaction) have been added to TiogaPass OCP platform, also TiogaPass can be bought off-the-shelf from Wiwynn. If we are lucky enough to have an IBV taking care of SKX-SP FSP maintenance, the industry at large will have an end to end open source firmware solution for SKX-SP based platform. Such solution is not 100% open source due to FSP, ME, etc, but it is a huge step forward.
The patch sets we would like to merge in for the planned releases are: a. https://review.coreboot.org/c/coreboot/+/40500 . b. https://review.coreboot.org/q/author:wiwynn.com+status:open c. https://review.coreboot.org/c/coreboot/+/40481
Thank you, Jonathan
On 4/22/20, 11:09 AM, "Patrick Georgi via coreboot" coreboot@coreboot.org wrote:
Hi everybody,
it's that time of year again: we should look into cutting a release. Not because there's anything noteworthy that we should bring out (although there certainly is), but because we have a 6-monthly cadence of giving our tree a new number and pushing out tarballs and press releases.
I plan to do the release on or shortly after May 11, and this announcement is in accordance to the process detailed on https://doc.coreboot.org/releases/checklist.html, so we're at the "~2 weeks prior to release" point right now.
As such, there are a number of things I ask of you (all of you subscribed to the list, but since you're reading this mail, yes, I mean you, personally!):
1. If you have anything big that you want to get in before the release, it's on you to maintain the changes responsibly and responsively so that it all works out in time. I'll gladly help coordinate things but I'm not interested in last-minute heroics, so get in touch with me ASAP.
2. Please try to postpone riskier refactorings and the like until after the release (unless they're ready to land in the next few days), so that people have a solid foundation to test their hardware on. Which gets us to the next point:
3. Please test your coreboot-supported gear if you can, report and/or fix issues, and upload fresh reports to the board-status repo. While we have no quality requirement for releases - they're _really_ only about giving the tree a new number, a release is a good opportunity to verify that what we have in the tree is still functional, with only limited work required to pin-point new issues (bisections since 4.11 should take 12 steps or less at this time).
4. Please check the preliminary release notes in Documentation/releases/coreboot-4.12-relnotes.md and add whatever happened since 4.11 that you think is noteworthy. If in doubt, push a change to gerrit and see what your fellow developers think about it.
Thanks, Patrick Georgi -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Hi Jonathan, I'll have a look, but I cannot help on the IIO stuff, as we still don't have access to Intel's confidential documents.
Kind Regards, Patrick Rudolph B.Sc. Electrical Engineering System Firmware Developer
9elements Agency GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: patrick.rudolph@9elements.com Phone: +49 234 / 68 94 188
Sitz der Gesellschaft: Bochum Handelsregister: Amtsgericht Bochum, HRB 13207 Geschäftsführung: Eray Basar, Sebastian Deutsch
Am Fr., 24. Apr. 2020 um 05:36 Uhr schrieb Jonathan Zhang (Infra) via coreboot coreboot@coreboot.org:
Hi Patrick,
Your help and dedication is much appreciated!
As we (FB and its partners) successfully finished bring-up of coreboot on CooperLake-SP based 1 socket platform, we are shifting our focus to exclusively on Cooperlake-SP based platfroms, away from using Skylake-SP based TiogaPass as the feature development vehicle.
This timing works well with the planned coreboot release. We have a number of SKX-SP platform related changes in the pipeline, we will try our best to work with the community to get them merged, then we will run a test pass, and we could report the status to the community (such as document what works and what further works are needed in Documentation/mainboard).
Many features (in particular smbios and BMC interaction) have been added to TiogaPass OCP platform, also TiogaPass can be bought off-the-shelf from Wiwynn. If we are lucky enough to have an IBV taking care of SKX-SP FSP maintenance, the industry at large will have an end to end open source firmware solution for SKX-SP based platform. Such solution is not 100% open source due to FSP, ME, etc, but it is a huge step forward.
The patch sets we would like to merge in for the planned releases are: a. https://review.coreboot.org/c/coreboot/+/40500 . b. https://review.coreboot.org/q/author:wiwynn.com+status:open c. https://review.coreboot.org/c/coreboot/+/40481
Thank you, Jonathan
On 4/22/20, 11:09 AM, "Patrick Georgi via coreboot" < coreboot@coreboot.org> wrote:
Hi everybody, it's that time of year again: we should look into cutting a release. Not because there's anything noteworthy that we should bring out (although there certainly is), but because we have a 6-monthly cadence of giving our tree a new number and pushing out tarballs and press releases. I plan to do the release on or shortly after May 11, and this announcement is in accordance to the process detailed on https://doc.coreboot.org/releases/checklist.html, so we're at the "~2 weeks prior to release" point right now. As such, there are a number of things I ask of you (all of you subscribed to the list, but since you're reading this mail, yes, I mean you, personally!): 1. If you have anything big that you want to get in before the release, it's on you to maintain the changes responsibly and responsively so that it all works out in time. I'll gladly help coordinate things but I'm not interested in last-minute heroics, so get in touch with me ASAP. 2. Please try to postpone riskier refactorings and the like until after the release (unless they're ready to land in the next few days), so that people have a solid foundation to test their hardware on. Which gets us to the next point: 3. Please test your coreboot-supported gear if you can, report and/or fix issues, and upload fresh reports to the board-status repo. While we have no quality requirement for releases - they're _really_ only about giving the tree a new number, a release is a good opportunity to verify that what we have in the tree is still functional, with only limited work required to pin-point new issues (bisections since 4.11 should take 12 steps or less at this time). 4. Please check the preliminary release notes in Documentation/releases/coreboot-4.12-relnotes.md and add whatever happened since 4.11 that you think is noteworthy. If in doubt, push a change to gerrit and see what your fellow developers think about it. Thanks, Patrick Georgi -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz derGesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi again,
A while I ago I announced my intent to do a new coreboot release. This is slated to happen next Monday, so we're now at the "~1 week prior to release" point of our release checklist (at https://doc.coreboot.org/releases/checklist.html).
So as a reminder: Please test the devices you have with master, fix (or at least report) regressions you encounter, propose additions to the release notes and generally try to make sure that the release looks like you want it to look.
Again, consider postponing risky changes to avoid shaking up things for your fellow co-developers and users.
Thanks, Patrick
-
Jonathan Zhang (Infra) -
Patrick Georgi -
Patrick Rudolph