On Thu, Apr 28, 2022 at 9:36 PM Felix Singer felixsinger@posteo.net wrote:
On Thu, 2022-04-28 at 08:22 -0400, Greg Troxel wrote:
Anastasia Klimchuk aklm@chromium.org writes:
I haven’t done any releases before, so tell me if I am wrong. But what I am thinking when looking at the list of issues: maybe we can have some time for “just fixing issues on master” and after that do a release branch? Does it make sense? “Some time” won’t take forever (AU winter maybe?). I have issue #353 assigned to me, so now it has to happen :)
My $0.02 from dealing with various projects.
Flashrom is small and I think it's best to do the release off master, getting everything done that needs to get done, and then beginning the process with feature freeze, moving to regression and doc fixes only, maybe alpha, beta, rc and then release. Only when there is a release create a branch that would be used for micro updates to the release while master is back open for development.
I think this depends on what's happening for the release. If code is just being added, the master branch is fine. It sounded like there might be a desire to remove code to do the release. In that case it probably makes sense to get as close to the release as possible, branch, then remove any code necessary for the release to happen. After the code is removed, maybe only allow stabilization changes and bugfixes onto that branch.
In order to make a release it is necessary to say no to further changes. It is always possible to improve, but that leads to never releasing, and users are better served with a series of better releases, as long as each one does not have significant regressions. This is easy to say and hard to do!
Creating a release branch before release means changes happen in master disconnected from release and there's backporting effort and a lot more work. Not branching incentivizes everyone to get the release done and hold their feature branches.
Good thoughts. Though, I think we shouldn't think about the actual release process too much now, because there are many issues from the past open and many questions unanswered.
For now, we should just focus on indentifying major issues, fixing these and see how that goes. Moving the issues Nico mentioned to the ticket system is a good first step. It could take some time until the actual release process can start, since I think there is lots of work to do to get to this point. However, things might look totally different in some weeks or months and so I would postpone this discussion. It doesn't make much sense to me to do that now.
I agree that it's too early to actually start the release process. It's good to have a well defined process though, so that should probably start now, before it's needed.
Maybe look over the coreboot release process and see what's useful to take from that. https://doc.coreboot.org/releases/checklist.html
Keep in mind though that coreboot releases are more of a snapshot of the codebase at a certain point in time than an actual stabilized release, so I'd imagine flashrom might want to do something like a testing checklist.
Martin