Changes between Version 1 and Version 2 of org/meetings/2014WinterDevMeeting/notes/TBBReleaseProcess


Ignore:
Timestamp:
Feb 25, 2014, 1:40:56 PM (5 years ago)
Author:
lunar
Comment:

formatting

Legend:

Unmodified
Added
Removed
Modified
  • org/meetings/2014WinterDevMeeting/notes/TBBReleaseProcess

    v1 v2  
    1 TBB Release Process. Feb 17 2014.
     1= TBB release process =
    22
    3 Release process currently: a new version of something comes out (e.g. Firefox), then Mike looks over the changes to see what needs fixing. At some point Mike makes a tag. Then Mike notifies people in an ad hoc way. Or Linus monitors the commit logs.
     3'''Abstract:''' Let's improve: roadmap, qa, translations, documentation, interaction with the support team, list of known issues
    44
    5 Once your 'make' is done, 'make match' compares your sha256sums to those of other makers.
     5== Minutes ==
    66
    7 Then 'make sign' to upload signatures of your packages.
     7=== Current release process ===
    88
    9 (Colin has some Selenium tests that he's working on. What's the status there?
     9A new version of something comes out (e.g. Firefox), then Mike looks over the changes to see what needs fixing. At some point Mike makes a tag. Then Mike notifies people in an ad hoc way. Or Linus monitors the commit logs.
    1010
    11 We also have access to the Mozilla Mercurial "tryserver" test servers. Only Mike's ssh key is authorized for now. Also they're the
    12 standard Mozilla tests, and probably many of them fail on Tor Browser.)
     11Once your `make` is done, `make match` compares your sha256sums to those of other makers.
     12
     13Then `make sign` to upload signatures of your packages.
     14
     15(Colin has some Selenium tests that he's working on. What's the status there?)
     16
     17(We also have access to the Mozilla Mercurial "tryserver" test servers. Only Mike's ssh key is authorized for now. Also they're the standard Mozilla tests, and probably many of them fail on Tor Browser.)
    1318
    1419Then Mike writes a blog post, uploads to www-master, updates RecommendedTBBVersions.
     20
     21=== Relationship with support ===
    1522
    1623But: support has no visibility into impending releases, and as soon as a new one comes out, there's a support spike. Plus, the support team doesn't know how to resolve the new issues yet either.
     
    2633TODO: Make a list this week of all the documentation that still mentions Vidalia, mis-states Windows TBB as a zip file, etc.
    2734
    28 What part of the release process takes the most time?
     35=== What part of the release process takes the most time? ===
    2936
    3037Answer: building, especially Firefox. It takes 24 to 48 hours before we get enough builds to have confidence. Though we can and do tell QA about builds once there's just one.
     
    3744
    3845Blockers:
     46
    3947- Erinn still signs individual packages. (Teaching normal users how to check sha256sum files is not going to happen.) We could instead put a shared key online in a safe place, and it generates those signatures.
    40 
    4148- The release process involves updating the website version file, and so every releaser needs access for that.
    42 
    4349- Everyone needs access to www-master to actually publish packages.
    4450
    45 Integration with Support:
     51=== Integration with support ===
    4652
    4753Support team wants a calendar of releases plus the features that are planned to accompany them.
     
    5157TODO: Comb through Trac tickets and make a list of known issues in normal English, intended for the support team.
    5258
    53 What about the roadmap? Does that constrain us too much?
     59=== What about the roadmap? Does that constrain us too much? ===
    5460
    5561Roger guesses Lunar doesn't need a roadmap more than one release into the future. Also, incremental changelogs: once you've merged stuff, there should be a way for him to know about it.
    5662
    57 How should TBB team better predict upcoming releases of its components?
     63=== How should TBB team better predict upcoming releases of its components? ===
     64
    5865New Tors, Python fixes, etc shouldn't all be surprises.
    5966
    6067Support needs to have input into the 'known issues' list.
    6168
    62 QA woe: All our manual QA people use English. Oops.
     69=== QA woe ===
    6370
    64 Should we get more people doing QA? Why not tell tor-talk about upcoming bundles? All our users are surprised by upcoming TBB releases, every time.
    65 Erinn suggests a blog post publicizing tor-qa list.
     71All our manual QA people use English. Oops.
     72
     73Should we get more people doing QA? Why not tell tor-talk about upcoming bundles? All our users are surprised by upcoming TBB releases, every time. Erinn suggests a blog post publicizing tor-qa list.
    6674
    6775There's a tbb-testcase trac keyword for things that would be good for automation.
    6876
    69 When Mike put out 3.5.2, he unrecommended 3.5.1, which caused the spike in support. A delay in unrecommending the old version would
    70 give more chance to find problems before forcing every user to notice. But of course that delays upgrades for (known) security issues.
     77When Mike put out 3.5.2, he unrecommended 3.5.1, which caused the spike in support. A delay in unrecommending the old version would give more chance to find problems before forcing every user to notice. But of course that delays upgrades for (known) security issues.
    7178
    72 How to reduce time-to-release?
     79=== How to reduce time-to-release? ===
    7380
    74 1) Only rebuild components when they have changed, so you don't recompile stuff that hasn't changed since last time. On the way.
    75 But tradeoff: keeping the VM around, with state on it, opens us up for security issues. This is a fine example where simplicity may be better.
    76 
    77 2) Nightlies will help make time-to-release faster, especially if the build triggers from the commit so you don't have to wait for the builder's human to wake up and launch it manually. Also nightlies will help with QA since some people will run the nightlies and find bugs early.
    78 
    79 3) Publish hashes of partial build components?
     811. Only rebuild components when they have changed, so you don't recompile stuff that hasn't changed since last time. On the way. But tradeoff: keeping the VM around, with state on it, opens us up for security issues. This is a fine example where simplicity may be better.
     822. Nightlies will help make time-to-release faster, especially if the build triggers from the commit so you don't have to wait for the builder's human to wake up and launch it manually. Also nightlies will help with QA since some people will run the nightlies and find bugs early.
     833. Publish hashes of partial build components?
    8084
    8185We need to get Nicolas a build machine that's as big as Erinn's, for nightlies among other things. Erinn has a plan for that.
     
    8387TBB team needs to strengthen their communication. And, how should the tbb team communicate with the support team?
    8488
    85 Spurious virus warnings! We need to submit all our packages to VirusTotal before release. In fact uploading to VirusTotal should be automated as part of the build-publish process, to make it happen as early as possible. Is uploading to VirusTotal sufficient to resolve all our QA false positives?
     89=== Spurious virus warnings! ===
     90
     91We need to submit all our packages to VirusTotal before release. In fact uploading to VirusTotal should be automated as part of the build-publish process, to make it happen as early as possible. Is uploading to VirusTotal sufficient to resolve all our QA false positives?