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.
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