Commit 122adfef authored by intrigeri's avatar intrigeri
Browse files

Merge remote-tracking branch 'origin/doc/roles-2018'

parents accc3f52 420d6296
......@@ -15,8 +15,9 @@ When the developer thinks it is good enough and has tested it, she must:
to grant you the necessary permissions)
- set the ticket's *QA Check* field to *Ready for QA*
- assign this ticket to nobody (aka. unassign it from yourself) by
default. Unless it's clear to you that the current release manager won't be able
or willing to do this specific review; in that case, _you_ shall try
default. Unless it's clear to you that nobody on the
[[Foundations Team|working_together/roles/foundations_team]] will be
able or willing to do this specific review; in that case, _you_ shall try
to find someone else to do the review, and assign the ticket
to them.
- point the ticket's *Feature Branch* field to your branch
......
......@@ -41,6 +41,21 @@ The Tails Foundations Team is responsible for:
<tails-rm@boum.org> to decide between themselves how they will share
the [[roles/release_manager]] shifts;
* reviewing'n'merging proposed branches in a timely manner (1 week in
general, up to 2 weeks if needed in exceptional cases). If a ticket
is flagged *Ready for QA*, but nobody on the Foundations Team can
take care of the review'n'merge, it's the Foundations Team's
responsibility to ask for help. These tickets can be tracked using:
- the "Release Manager View: VERSION";
- the
[Ready for QA, with no assignee](https://labs.riseup.net/code/projects/tails/issues?query_id=194)
view;
- [Ready for QA](https://labs.riseup.net/code/projects/tails/issues?query_id=117);
* deal with last minute emergency fixes needed during release process,
e.g. [[!tails_ticket 14962]];
* if time allows, do whatever code task the project sees as
top-priority, such as fixing Holes in the Roof, important bugs, or
implementing a feature that is needed to keep Tails relevant.
......@@ -32,17 +32,6 @@
- Ensure you have found a _Trusted Reproducer_ and write who this is
in the [[contribute/calendar]].
## Around two weeks before the freeze
- Have a look at recent changes
in [Torbutton](https://gitweb.torproject.org/torbutton.git), and
make sure they are compatible with our configuration.
- Check that the list of backends we ship in `/usr/lib/cups/backend`
are all listed in the (patched) `/etc/apparmor.d/usr.sbin.cups`:
* backends shipped in [[!debpkg cups-daemon]] should have `ixr`
* other backends should have `Cx -> third_party`
If anything doesn't match this, let intrigeri know.
## The Friday before the release date
We need to coordinate our Tails release with the Tor Browser
......@@ -68,19 +57,6 @@ See the
[[Upgrading the Tor Browser|contribute/release_process/tor-browser]]
page for details.
## Continuously
The RM is still the fallback for reviewing'n'merging stuff relatively
promptly. If a ticket is flagged *Ready for QA*, but the RM cannot
take care of the review'n'merge, it's the RM's
responsibility to ask for help. These tickets can be tracked using:
* the "Release Manager View: VERSION";
* the
[Ready for QA, with no assignee](https://labs.riseup.net/code/projects/tails/issues?query_id=194)
view;
* [Ready for QA](https://labs.riseup.net/code/projects/tails/issues?query_id=117).
## At least for the first release of the year
Have a look at scenarios or features added or modified since last time
......
......@@ -66,17 +66,33 @@ for example:
* keep backups up-to-date
* keep Jenkins plugins up-to-date, by upgrading any plugin that satisfies
at least one of these conditions:
- only brings security fixes
- brings security fixes
- fixes bugs we're affected by
- brings new feature we are interested in, without breaking the ones we rely on
- is needed to upgrade another plugin that we want to upgrade
- is required by a system upgrade (e.g. of the Jenkins packages)
* report bugs identified in Jenkins plugins after they have been upgraded (both
on the upstream bug tracker and on our own one)
* act as the de facto interface between Tails and the servers hosting
* act as the de facto interface between Tails and the people hosting
our services (boum.org, immerda.ch) for non-trivial requests
* when a sysadmin shift includes the beginning of a yearly quarter, ensure that
sysadmin shifts are filled and agreed on for the next two quarters
* quarterly: self-evaluate our work and report to the -summit@ mailing list
* When the deadline for taking over a given maintenance task (see
below) has passed, the sysadmin on duty must make it clear s·he's
handling the problem before starting to work on it, in order to
avoid work duplication.
## Outside of sysadmin shifts
* Read email at least twice a week to check if the sysadmin currently
on duty needs help.
* Once 48 hours have passed after a problem was identified, the
sysadmins not currently on duty can/should take over maintenance
tasks if the on duty sysadmin is MIA; for critical problems this
delay shall be reduced.
<a id="tools"></a>
......
Supports Markdown
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