Commit 9faed3dd authored by intrigeri's avatar intrigeri

Retire the experimental branch.

Closes: #11202
parent d08c91ba
Pipeline #1839466 skipped
......@@ -147,15 +147,6 @@ Feature: custom APT sources to build branches
Then I should see the 'feature-jessie' suite
And I should see the 'feature-7756-reintroduce-whisperback' suite
Scenario: build from the experimental branch
Given I am working on the experimental branch based on devel
And config/APT_overlays.d contains 'feature-foo'
And config/APT_overlays.d contains 'bugfix-bar'
When I successfully run tails-custom-apt-sources
Then I should see the 'devel' suite
And I should see the 'feature-foo' suite
And I should see the 'bugfix-bar' suite
Scenario: build from a feature branch with overlays based on devel
Given I am working on the feature/icedove branch based on devel
And config/APT_overlays.d contains 'feature-icedove'
......
......@@ -88,12 +88,7 @@ At release time, the release manager:
3. merges the release branch into other base branches as needed, and
ensures that all resulting `config/APT_overlays.d/`:s make sense.
Given this, the `experimental` branch doesn't need to be seen as
a base branch anymore; instead, it can be seen as an integration
branch of overlays on top of the `devel` one: its `config/APT_overlays.d/`
will merely add, on top of `devel`'s one, the list of APT suites that WIP
branches merged into `experimental` have introduced. On the other
hand, `feature/jessie` does need to be a base branch: we want to be
Note that a branch like `feature/jessie` needs to be a base branch: we want to be
able to work on topic branches forked off `feature/jessie`.
SSH access
......
......@@ -180,19 +180,6 @@ merged before being renamed, and our Jenkins instance will not build nor
test it, so you won't get notifications for a branch that you know is
breaking the build and/or the test suite.
#### experimental
Generally, it's `devel` plus a few topic branches merged in.
These topic branches are not ready enough to be merged into devel, but
we seriously would like to get them fit for the next stable release,
so this branch serves to test all these new features and bugfixes by
building / getting a single image. The history of this branch is
frequently rewritten and must not be used as the basis of
any development.
Please note that the `experimental` branch can be broken, have awful
security problems and so on. No guarantee, blablabla.
Promotion material
------------------
......
......@@ -31,8 +31,7 @@ existing ones are still correct.
## Test your code
A branch proposed for review and merge must have been tested when applied
against either experimental, or against the target branch(es) of the requested
merge.
against the target branch(es) of the requested merge.
## Do not break the build... or get reverted
......
......@@ -32,12 +32,11 @@
Merge the branch with `--no-ff`:
- for a new feature: into `devel`; then merge `devel` into
`experimental`
- for a new feature: into `devel`
- for a fix on top on the last RC: into `testing`; then merge
`testing` into `devel`, and `devel` into `experimental`
`testing` into `devel`
- for a fix on top of the last stable: into `stable`; then merge
`stable` into `devel`, and `devel` into `experimental`
`stable` into `devel`
<a id="fix-committed"></a>
......
......@@ -7,7 +7,6 @@ branch name, e.g. `bugfix/7173-upgrade-syslinux`.
When the developer thinks it is good enough and has tested it, she must:
- if you have the commit bit, merge the topic branch into the `experimental` one
- set the ticket's *Status* field to *In Progress*
- set the ticket's *QA Check* field to *Ready for QA*
- assign this ticket to nobody (aka. unassign it from yourself) by
......
......@@ -1065,28 +1065,12 @@ this, and skip what does not make sense for a RC.
from the previous stable release will usually have had us prepare
for an emergency release that was never made.
1. Pull `master` back and merge it into `stable`, and in turn into
`devel` and `experimental`.
`devel`
1. Follow the
[[post-release|contribute/APT_repository#workflow-post-release]] APT
repository documentation. Make sure there are upgrade-description
files for any new versions that were added.
1. Push the resulting branches.
1. If this was a major release, then reset experimental:
- take note of branches merged into `experimental`, but not into
`devel`:
git log --pretty=oneline --color=never --merges devel..experimental \
| /bin/grep 'into experimental$' \
| sed -e 's,^[a-f0-9]\+\s\+,,' | sort -u
- `git checkout experimental && git reset --hard devel`
- merge additional Git branches into experimental
for branch in $UNMERGED_BRANCHES ; do
git merge $branch
done
- `git push --force origin experimental:experimental`
1. Make sure Jenkins manages to build all updated major branches fine:
<https://jenkins.tails.boum.org/>.
1. Delete the _Release Manager View for $VERSION_ Redmine custom query.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment