Hi Anastasia,
On 13.03.22 08:28, Anastasia Klimchuk wrote:
I've been scrolling through the commit log from v1.1 (the last release I was involved) to today's master.
I am wondering why v1.1, I know the latest released version is v1.2? Is there anything about v1.2 release why you don’t count it?
tl;dr it was done in a hurry, IIRC.
Starting with 1.0, I maintained release branches per minor release (1.0.x, 1.1.x). The plan was to also make point releases on these branches if any fixes made it into a new release (and also apply to a release branch). I assume nobody kept track what might also apply to these branches until today. And to be honest, I forgot if there just wasn't anything applicable between v1.1 and v1.2 or if we didn't check ;)
v1.1 was also the last release before some incredibly chaotic development started. To converge forks, some people seemed to push simple diffs of up- and downstream to upstream flashrom. Not sure what drove it, but the idea seems to have been that downstream was ahead, while it was actually years behind. Some of such patches made it into the master branch and I wanted to try at least one time to figure out if there was anything left that wasn't reverted yet.
I suggest that we freeze the master branch for everything that is neither a fix nor on the list (or a similar case that I missed)
But how can we freeze master… that would mean no one can do any work? Maybe I am missing something?
No you didn't miss anything :) it would be a very desperate measure. However, I see no other solution to make progress again without forking or further stalling a release. And after 2 years I think the project has waited long enough.
This is also why I suggested that we can drop suspicious code from a release branch (i.e. we could branch 1.3.x now and then delete code on that branch without affecting master). Then the freeze might be over really quickly. We'd only need to decide what to do with the code instead of fixing every- thing at once. However, if that would result in no action on the master branch until we branch 1.4.x, I would vote to delete the code on the master branch too.
Also I am looking at two lists. The first one, is my understanding correct, those can be bugs in bugtracker (which we will have soon right? :)) and assigned to different people?
Very much so.
The second list Backport, are those good commits that go to the release?> What is happening with all the other commits? (between v1.1 and now that would be a lot of them). I am just trying to understand the technical process.
This is about the older release branches. I just wrote down the commits that looked like they might fix something that was already an issue years ago. IOW, the second list doesn't matter for the v1.3 release.
Nico