Re: [flashrom] Future flashrom development

[Antonio Ospite]

On Fri, 13 Oct 2017 08:01:00 +0200
Peter Lemenkov  wrote:
> Hello Nico,
>
> 2017-10-13 2:40 GMT+02:00 Nico Huber :
> > 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?
>
> 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.

FWIW I too am in favor of a more "usual" branching model.

Besides, git users kind of expect "master" to be the development branch
with all that this entails: e.g. no hard promises on stability,
possible risk of regressions compared to the latest tagged release.

Tags and versioned branches can be used to track and support stable
releases long term, and wild experiments can still be done in topic
branches, can't they?

Ciao,
   Antonio

Future flashrom development

[Stefan Tauner]

On Fri, 13 Oct 2017 17:58:05 +0200
Antonio Ospite  wrote:
> FWIW I too am in favor of a more "usual" branching model.
>
> Besides, git users kind of expect "master" to be the development branch
> with all that this entails: e.g. no hard promises on stability,
> possible risk of regressions compared to the latest tagged release.

flashrom gets compiled by people not knowing what git or master even
is following some random tutorial on the internet.
The whole purpose of having no master branch is to make everyone aware
of the different behavior of the two main branches. For some (including
those working with external programmers) staging is fine, for others
(e.g. newbies updating their firmware via -p internal for the first
time, package maintainers and other rather conservatives) stable is the
way to go.
> Tags and versioned branches can be used to track and support stable
> releases long term, and wild experiments can still be done in topic
> branches, can't they?

Topic branches are a pita in gerrit and get only tested by those
interested in the respective feature. Getting such changes into staging
would get by far more tested in the wild.