Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

September endgame #59271

Closed
mjbvz opened this issue Sep 24, 2018 · 9 comments
Closed

September endgame #59271

mjbvz opened this issue Sep 24, 2018 · 9 comments
Assignees
@mjbvz
Labels
endgame-plan VS Code - Next release plan for endgame
Milestone
September 2018

Comments

@mjbvz
Copy link
Collaborator

mjbvz commented Sep 24, 2018 •
edited
Loading

  • September 24 Code freeze for the endgame
  • September 28 Endgame done

Note: The Insiders build needs to be in the wild for 24 hours before we can enter the last phase of the endgame.

Monday
  • Run OSS tool endgame master
    • The LCA review of the ThirdPartyNotices.txt files is not needed anymore
  • Code freeze at 5pm PT
  • Ensure we have a green build on all platforms at 5pm PT
  • All test items contain sufficiently comprehensive test descriptions by 6pm PT
  • Update your availability for testing here - https://vscode-tools.azurewebsites.net/
Tuesday
  • Test plan items assigned (using https://vscode-tools.azurewebsites.net/)
    • Run the tool multiple times to balance load if test items come in later and assignments are already made
  • All closed feature-requests either have a verification-needed or on-testplan tag
  • Test build starts at 7am CET
  • Test plan ready by 8am CET
  • Testing
  • Verification needed
Wednesday
Thursday
  • Fixing (scrutiny sets in - major bugs only - to be discussed in stand-up meeting, labeled as candidate)
  • Verification
  • Check new OSS usage is entered into the OSS registry owner
Friday
Friday/Monday
  • Branch code to `release/<x.y> endgame master
  • Bump up the version in package.json - endgame master
  • Announce master is open for business endgame master
  • Let Daniel Ye know that the release branch release/<x.y> got created and that translation should be pulled from there and that the pull request has to be created against that branch endgame master
  • Polish release notes redmond
Monday - Wednesday

Note: The Insiders build needs to be in the wild for 24 hours before we can enter the last phase of the endgame.

Wednesday/Thursday
  • Build stable for all platforms endgame master
  • Make rpm signing request @Tyriar
  • Sanity check of installable bits
    • Windows
      • signed installer 32-bit owner
      • signed installer 64-bit owner
      • signed user installer 32-bit owner
      • signed user installer 64-bit owner
      • zip 32-bit owner
      • zip 64-bit owner
    • OS X - owner
    • Linux
      • deb package 32-bit owner
      • deb package 64-bit owner
      • rpm package 64-bit owner
      • rpm package 32-bit owner
      • archives owner
  • Publish website @gregvanl
  • Publish to stable endgame master
  • Add a git tag to HEAD of release/<x.y> in format x.y.z (for vscode.d.ts download) endgame master
  • Publish deb and rpms to repositories manually @Tyriar
  • Enable scheduled insider builds endgame master
  • Twitter announcement @auchenberg

Recovery Build

We release a recovery build with a handful of critical fixes and translation updates a few days after a release. The candidate fixes are reviewed by the development team and are assigned to the recovery milestone. We want to be restrictive about the included candidates. The mindset is "we will lose users if we do not include the fix". Here are some examples:

  • data loss
  • a regression that users complain loudly about in issues or twitter
  • a significant performance regressions
  • an issue that impacts many users as indicated by telemetry data
  • an embarrassing UI glitch
  • critical security fixes
  • an issue that impacts extensions or is an API regression

Check list

  • Create a milestone <Month> Recovery <year> owner
  • Include an issue 'update translations' owner
  • Assign candidate issues to the recovery milestone team
  • Review the candidate issues, and if they pass the review assign them to the recovery milestone team
  • All candiate fixes are peer reviewed and pushed to master and then cherry-picked into the release branch team
  • Initiate insiders build from master
  • Issues are tested in the insiders team
  • Build stable for all platforms from release branch owner
  • Make rpm signing request @Tyriar
  • Issues are verified on stable build and the verified label is added owner
  • Check https://github.com/Microsoft/vscode/compare/release/<x.y> to ensure no other commits have been made in the release branch owner
  • Update the release notes and include a link to a query for the fixed issues @gregvanl
  • Smoketest stable bits
    • Windows - owner
    • OS X - owner
    • Linux - owner
  • Sanity check installable stable bits that have not been smoke tested
    • Windows
      • signed installer 32-bit owner
      • signed installer 64-bit owner
      • zip 32-bit owner
      • zip 64-bit owner
    • OS X - owner
    • Linux
      • deb package 32-bit owner
      • deb package 64-bit owner
      • rpm package 64-bit owner
      • rpm package 32-bit owner
      • archives owner
  • Publish website @gregvanl
  • Publish stable build owner
  • Publish deb and rpms to repositories manually @Tyriar
  • Add a git tag to HEAD of release/<x.y> in format x.y.z
@mjbvz mjbvz added the endgame-plan VS Code - Next release plan for endgame label Sep 24, 2018
@mjbvz mjbvz added this to the September 2018 milestone Sep 24, 2018
@mjbvz mjbvz self-assigned this Sep 24, 2018
@chpxu
Copy link

chpxu commented Sep 26, 2018

Add this to the iteration plan and Wiki? @mjbvz

@kieferrm kieferrm mentioned this issue Sep 26, 2018
Closed
18 tasks
@paterasMSFT
Copy link

paterasMSFT commented Oct 5, 2018 •
edited
Loading

Could you use dates instead of days of the week for these?

@tkrajacic
Copy link

… also even though it has been said before that the release can be expected to be done in the week AFTER the month is over, why does literally the second line in this issue already contradict that?

September 28 Endgame done

(And why not plan to be ready actually AT the end of the month?)

But I agree with @paterasMSFT that it would be a bit easier to follow along if there were dates instead of just "Monday" etc.

@Tyriar
Copy link
Member

Tyriar commented Oct 5, 2018

@tkrajacic "Endgame done" indicates the time in which the "endgame week" ends, we normally release the following week in "debt week". See https://github.com/Microsoft/vscode/wiki/Development-Process#inside-an-iteration

@tkrajacic
Copy link

@Tyriar The fact that I would have to look that up somewhere is precisely my point. This is not meant as bashing the work but rather pointing out that it can be confusing for no obvious reason.

@octref
Copy link
Contributor

octref commented Oct 5, 2018

Maybe we can add and item to the dates to better inform the community, like

  • September 24 Code freeze for the endgame
  • September 28 Endgame done
  • October 4 Release (And keep this updated, in case the release slips)

in both the plan issue and endgame issue.

@connorshea
Copy link
Contributor

I would also appreciate dates on these 👍

@Tyriar
Copy link
Member

Tyriar commented Oct 5, 2018

We should probably also link to the wiki in the endgame template.

@Tyriar
Copy link
Member

Tyriar commented Oct 5, 2018

Updated: https://github.com/Microsoft/vscode/wiki/Running-the-Endgame#schedule-template

@isidorn isidorn closed this as completed Oct 9, 2018
@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 23, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@mjbvz mjbvz

Labels
endgame-plan VS Code - Next release plan for endgame
Projects
None yet
Milestone
September 2018
Development

No branches or pull requests
8 participants
@tkrajacic @isidorn @Tyriar @connorshea @octref @mjbvz @chpxu @paterasMSFT