Hi flashrom fellows,
some of us have picked a new release process for flashrom 1.3 that ignores the problems of the master branch but will attend to them on a separate branch. This leaves us without a strategy to get future releases done with less hassle. It also feels quite frustrating be- cause I fear it takes incentive away to fix the master branch. And hence increases the incentive for myself to abandon said branch.
During a phone call with Felix, I explained the options I see roughly as follows. There are probably more options, feel free to discuss others as well. These just came to my head.
1. Full reset: Branch off 1.2.x before the master branch started to make trouble. Also reset the Gerrit privileges to a state where only people got merge rights after they earned trust by the pre- existing maintainers (people with those rights); to prevent that history repeats itself.
So far this seemed to be unacceptable by the Google team. The rest of this email will assume that we won't be doing this. If it turns out I'm wrong, this would be my preferred solution and we won't have to discuss anything below.
2. Try harder: Keep working on the current master branch. Try to fix the process as we go along.
This is unacceptable to me. We have tried this already and I have not seen things getting better. Building up on a broken state is most often harder than rewinding to a good state and starting new things from scratch. Working on this branch has not been fun since flashrom 1.2. Beside that, the master branch hasn't provided any- thing that I could use in my day job for years (not as a develop- ment tool and definitely not in our products).
3. Compromise: The current situation evolved due to a highly dynamic development process that is roughly the opposite of what we had before we tried to converge upstream and chromium development. Also, adding many new developers that are used to a very different process requires a lot of communication (IMO) which didn't happen.
We could accept these different development strategies and work on two branches. Not(!) competing branches but branches that complement each other. Something like this was actually proposed before [1]. The rough idea: we could have a 'stable' branch and a more dynamic one. Back then we called the latter 'staging'. Merging commits to the 'stable' branch would be limited to maintainers who know flash- rom well enough and trust each other. To be honest, I wouldn't care much what happens on the 'staging' branch, who gets to merge etc.
There were often reservations if this could work without diverging the branches. But there are strategies to avoid it. For instance, a regular `git merge` onto the 'staging' branch could avoid that.
To give it a good start, I would also suggest to base a 'stable' branch on 1.2.x.
4. Divide: If we don't find a compromise, I'll have to continue my work on a new branch. I wouldn't care then if things diverge. Details depend mostly on who would like to join the effort. It would likely start on 1.2.x with things added from the current master branch (might get things through review again, or also cherry pick real cherries directly without going through Gerrit).
Quite unappealing because it would push contributors to choose a branch. And we would have to discuss how to deal with future releases.
You may notice that most of my ideas suggest rewinding to 1.2.x. Beside easing further development on a reasonable code base, there is one more thing driving me: The master branch contains many commits that caused awkward feelings. I think it would help working together if we wouldn't be reminded of them all the time.
Nico
[1] https://www.flashrom.org/index.php?title=Development_Guidelines&oldid=22...
-
Nico Huber