Hi Richard,
thanks for your thoughts. This has woken some more ideas in my mind, how to express current flashrom troubles.
On 17.10.22 11:26, Richard Hughes wrote:
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.
I very much agree to a shorter release cycle. Maybe not monthly, but every 3 months would be worth a shot, IMO. When we still did releases, it was about 1 per year. But back then we had little time to spare for releases. Regressions can be much more severe though, and with the cur- rent development the story might look like: "sorry for the regression! you may have to acquire a hot-air soldering station now to fix your PC. when you are done, please try to help us to debug the issue. although, even if you do, we may not fix the issue in a release if there's a chance that something would regress for a flashrom stakeholder.". So to say, we have other problems that need to be addressed before we can dream about a release cycle.
The problems seem to run very deep. It's not easy to put into words. I'll try to sketch one thought briefly as I don't have much time: One issue is a denial of service on many levels. One level (kind of my DoS) is the bug fixing. Because I've seen it burning out people (including myself) when one tries to clean up behind others, I argue against fixing bugs that other people introduced. This has went so far that I even stopped pushing reverts for others. Because last time I pushed a revert of a three-line patch with three flawed lines, people made a drama of it.
Nico