[flashrom] Future flashrom development

[Nico Huber]

Hi Peter,

On 13.10.2017 08:01, Peter Lemenkov wrote:
> Hello Nico,
> 
> 2017-10-13 2:40 GMT+02:00 Nico Huber <nico.h at gmx.de>:
> 
>> So I propose the following: Forget the two branches model, start
>> a `master` branch with either the current state of `staging` or
>> my proposed move to `stable` [3] and release flashrom-1.0 right
>> away.
> 
> I believe staging/devel/etc branches in projects managed with git are
> usually a troublesome legacy from old CVS/SVN days where
> branching/tagging and patch management were expensive. They shouldn't
> have even copied into Git repositores at all. Also flashrom
> historically has a very flat and straightforward development model, so
> why making two branches at all?

I saw some benefit in the idea to merge everything into one branch
(staging) first and only move the commits to the other branch after
they ripened somehow (more tested, more eyes looked through them).
I did indeed look into some patches again when I prepared to move
them to the stable branch and spotted some issues. You are abso-
lutely right, though, that there is no need to do it this way with
Git. And one can easily argue that things get even more tested when
they land on a master branch right away.

Also it turned out, that merging everything to staging first, was
only my own interpretation and not the original intention behind the
two-branches idea.

> 
>  From the package maintainer's point of view it would be easier and
> simpler from if flashrom just have one single monotonically increasing
> branch (master?) with tags applied to some commits eventually (I
> prefer more frequent tagging though), rather than two branches where
> the purpose of one is to be blindly merged into another.

Blindly merging from one branch to the other was never the idea. Anyway,
I'm still not sure if I understand the original two-branches idea now,
so won't argue about that.

Personally, I'd prefer release branches and to tag only on them. After
branching, you wouldn't have to take any special care about what is
done on the master branch (i.e. a release doesn't affect regular deve-
lopment).

Nico