|
|
| (4 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. |
|
| |
| = 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).
| |
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