[prev in list] [next in list] [prev in thread] [next in thread] 

List:       flashrom
Subject:    [flashrom] Re: Release preparations
From:       Nico Huber <nico.h () gmx ! de>
Date:       2022-03-13 15:28:33
Message-ID: 7d698354-cff1-80a9-91e7-090ad0cb1279 () gmx ! de
[Download RAW message or body]

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
_______________________________________________
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-leave@flashrom.org

[prev in list] [next in list] [prev in thread] [next in thread]