On Fri, 13 Oct 2017 08:01:00 +0200 Peter Lemenkov lemenkov@gmail.com wrote:
Hello Nico,
2017-10-13 2:40 GMT+02:00 Nico Huber nico.h@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?
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
On Fri, 13 Oct 2017 17:58:05 +0200 Antonio Ospite ao2@ao2.it 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.
-
Antonio Ospite -
Stefan Tauner