Talk:Development Guidelines: Difference between revisions

From flashrom
Jump to navigation Jump to search
No edit summary
(drop comment about branch-point tags)
 
(2 intermediate revisions by the same user not shown)
Line 4: Line 4:


= Branches =
= Branches =
'''''Mostly rewritten.
=== Historical ===
Till the release of flashrom 0.9.9 there was basically a single branch
(trunk) where linear development happened. After 0.9.9 it was decided
to switch to Git and a two branch model, a ''stable'' and a ''staging''
branch. This led to some confusion and as nobody who had access to the
''stable'' branch had the time to work on it, development continued
about one year after the 0.9.9 release on a ''staging'' branch at
coreboot.org. Despite its name, we strived to keep flashrom's quality
and hoped that everything would be merged to ''stable'' once work
continues there.
=== ''master'' branch ===
The historical ''staging'' branch was finally renamed to ''master''.
As usual there is no quality promise for the state of the code on the
''master'' branch. Even though we will try to keep the regression
rate as low as possible, the main purpose of the branch is to merge
new commits and make them available to a broader audience for testing.


=== Release branches (e.g. ''1.0.x'') ===
=== Release branches (e.g. ''1.0.x'') ===
Branching for a new release can happen at any point in time when a
commit (branch point) on ''master'' seems to be in good shape and was
reasonably tested after previous invasive changes. Between the branch
point and the release, every fix pushed for ''master'' for a problem
that also persist on the release branch shall be backported. The same
also applies after the release for the latest release branch and,
optionally, for any earlier release branch that is still maintained
for other reasons (e.g. part of a long term distribution).
Whenever a release branch has no further unmerged commits in queue
and is not awaiting backported fixes, a release candidate (RC) can be
tagged on that branch. This can also be the original branch point. The
RC shall undergo extensive build tests and be publicly advertised as
ready for testing. Not less than five days after the RC, a release
can be tagged if no regressions showed up.
Release-branch names follow the pattern '''''<major>.<minor>.x'''''
(e.g. ''1.0.x''). The first release of a branch is tagged
'''''v<major>.<minor>''''', without a point-release number (e.g.
''v1.0''). Every following release from the same branch, will have
a point-release number starting with '''''.1''''' (e.g. ''v1.0.1'').


'''''We could add some note about stability of the first release from a branch, e.g. like Linux say that only the first point release is stable. I'd bet, though, that it won't make a difference in practice: The quality of point releases is always better, not matter how you advertise it.
'''''We could add some note about stability of the first release from a branch, e.g. like Linux say that only the first point release is stable. I'd bet, though, that it won't make a difference in practice: The quality of point releases is always better, not matter how you advertise it.
'''''I guess we should always tag the branch points as well, otherwise the version strings for builds from master would be stuck on the last branch point that actually was an RC (or v0.9.9 for now). Any suggestion for tag names? b1.0? maybe rather p1.0 (for post-1.0)? something that's not too easy to confuse with the branch name
= Patch submission =
'''''Keep
== Sign-off Procedure ==
'''''Keep


= Reviews =
= Reviews =


'''''Maybe reword, mention where reviews may happen (I think we should ask each contributor on the ML / github if he agrees to switch to Gerrit). Btw. is there a option in github to send emails, like we have it on flashrom-gerrit?
'''''Maybe reword, mention where reviews may happen (I think we should ask each contributor on the ML / github if he agrees to switch to Gerrit). Btw. is there a option in github to send emails, like we have it on flashrom-gerrit?
== Acked-by ==
'''''Drop, everything goes through Gerrit


== Adding/reviewing a new flash chip ==
== Adding/reviewing a new flash chip ==


'''''Keep, actually TLDR; maybe move somewhere else
'''''Keep, actually TLDR; maybe move somewhere else
= Committing =
'''''Replace by:
= Merging to branches =
Merging to branches is limited to the "flashrom developers" group on
Gerrit. This means every patch reviewed somewhere else (e.g. mailing
list or github) must finally be pushed to Gerrit. The following rules
apply, some are already enforced by Gerrit:
* Every commit has to be reviewed and needs at least one +2 that was not given by the commit's author.
* Except, if a commit is authored by more than one person, each author may +2 the other author's changes.
* Merging should not take place within less than 24 hours after the review started (i.e. the first message by a reviewer on Gerrit).
* Finally, before hitting ''Submit'', one is reponsible to check that all comments have been addressed, especially if there was a negative review (-1).

Latest revision as of 16:50, 18 February 2018

Hey, I'd like to propose a lot of changes here, now that we'll work with a single master branch on Gerrit. I'll leave some comments in bold & italic.

Branches

Release branches (e.g. 1.0.x)

We could add some note about stability of the first release from a branch, e.g. like Linux say that only the first point release is stable. I'd bet, though, that it won't make a difference in practice: The quality of point releases is always better, not matter how you advertise it.

Reviews

Maybe reword, mention where reviews may happen (I think we should ask each contributor on the ML / github if he agrees to switch to Gerrit). Btw. is there a option in github to send emails, like we have it on flashrom-gerrit?

Adding/reviewing a new flash chip

Keep, actually TLDR; maybe move somewhere else