Hi all (again),
We (Angel) just took the time to reorder the previous replies so that we can respond to them in-line.
On Mon, Oct 17, 2022 at 11:34 AM Richard Hughes hughsient@gmail.com wrote:
On Mon, 17 Oct 2022 at 12:24, Edward O'Callaghan quasisec@google.com wrote:
On Mon, 17 Oct 2022 at 20:27, Richard Hughes hughsient@gmail.com wrote:
Hi all,
Perhaps a way forward would be to tag a rc release, ask distributors to package and test it (e.g. pushing to Fedora Rawhide, but not Fedora 36), and then push the actual official release a week or two later?
Certainly aiming to do releases monthly is much healthier than doing releases every few years. I think it's much more achievable to set the expectation to the end user "sorry for the regression! it'll be fixed in your distro in ~3 weeks, in the meantime use the previous release" than trying to squash every bug and add all the features before tagging a mythical beautiful bug-free "feature complete" release.
We (Angel) agree that striving for a "feature complete" release is not good: in a way, it resembles maladaptive daydreaming. Having a faster-paced release cadence is a good idea, too. However, flashrom isn't the kind of project where regressions can be taken lightly, especially those which can render users' hardware unusable. It's important to not forget that flashrom's userbase is extremely wide, with users that just want to update their BIOS without having to install Windows, experienced coreboot developers, and anything in between and even out-of-bounds. Some people even use flashrom on DOS: if there's a bug that corrupts the flash chip contents, it may not be possible to get a different flashrom version without rebooting the system (in other words, they are doomed).
Richard.
I very much like Richard's pragmatic approach here.
It would be my view that we should re-evaluate branch critical bugs (sb600spi map issue + build system stuff are the two the most prominent in my mind at the moment) and just cut a release branch, stabilise that with some cherry-picks of any residue items. Forge forwards from that with a more regular cadence exactly how Richard suggests. If some critical issue comes up we can do a point release.
Sounds good, thank you. Not sure which are the most pressing concerns, but definitely not everything currently listed in https://ticket.coreboot.org/issues/353 is required to make a release. Another option would be to make a new branch for the next (probably v1.3, but it could be something else like v1.2.1 too?) release: one could base the next release off the master branch with the potentially broken parts removed, or one could base it off the v1.2 branch and cherry-pick the most important changes from master. At first, we (Angel) were unsure which approach would be better, but the second approach sounds more appealing the more we think about it: it would allow us (the flashrom community) to calmly re-review (and possibly re-design) all the changes since the v1.2 release. It will be a *lot* of work, but it will allow us (the flashrom community) to address any concerns about review thoroughness (for lack of a better word) and settle them down once and for all.
Kindest regards, Edward.
If it helps, a monthly release seems to be the sweet spot for fwupd, from a "writing release notes" and "getting fixes into users hands" point of view. There's no point having a "no regressions" rule as this is software, and even the most benign of changes can have some unknown side effect -- it's much better to just make releases "cheap" and do lots of them. In fwupd the main branch is always "releasable" so if we have a high-priority fix or security issue we just merge, write release notes, tag, push outside the usual release cadence.
This is what coreboot strives for, too: coreboot's master branch is supposed to work at all times, and releases are just "glorified" commits from the master branch. The release cadence for coreboot is about 3 months (it used to be 6 months), which should also work for flashrom. However, flashrom's master branch isn't "releasable" at the moment even though it should be.
Richard
Best regards, Angel