October Iteration Plan

[egamma]

This plan captures what we work on during October. We will ship early November.

Endgame Schedule

• October, 24th Code freeze for the endgame
• October, 30th Endgame done

Verification

• Verification (wiki): since there are quite some old bugs to verify we verify by age, youngest first. The queries are:
  • Verification needed
  • October Bugs

Monday

• Code freeze at 5pm PT
• Ensure we have a green build on all platforms
• All test items contain sufficiently comprehensive test descriptions by 6pm PT

Tuesday

• Test build starts at 7am CET / 10pm PT on Monday
• Test plan ready by 8am CET / 11pm PT on Monday
• Testing

Wednesday

• Testing
• Remind team members to assign issues that they intend to fix to the October milestone
• Fixing (self-assigned, milestone assigned)
• Verification (queries above)

Thursday

• Fixing (scrutiny sets in - major bugs only - to be discussed in stand-up meeting, labeled as candidate)
• Verification (queries above)
• Add/update shrink-wrap files for built-in extensions if needed (see instructions)
• Update OSSREADME.json for built-in extensions based on differences to generated npm-shrinkwrap.json files if basero
• Run OSS tool after merging shrink-wrap findings Benjamin Pasero (@bpasero)
  • The LCA review of the ThirdPartyNotices.txt files is not needed anymore
• Check new OSS usage is entered into the OSS registry Benjamin Pasero (@bpasero)

Friday

• Satellite modules/npm packages ready, version updated, smoke tested
  • vscode Johannes Rieken (@jrieken)
  • yo generator Martin Aeschlimann (@aeschli)
  • vsce João Moreno (@joaomoreno)
  • node debug Andre Weinand (@weinand)
  • node debug2 roblourens
• Translation input - Dirk Bäumer (@dbaeumer)
• Verification (queries above)
• Fixing (only critical bugs - no string changes)
• All release notes updated. Release notes are collected in a file named 1_7.md in this repo directory
  • alexandrudima
  • Andre Weinand (@weinand)
  • Benjamin Pasero (@bpasero) 
  • Christof Marti (@chrmarti)
  • Daniel Imms (@Tyriar)
  • Dirk Bäumer (@dbaeumer)
  • Erich Gamma (@egamma)
  • Isidor Nikolic (@isidorn) 
  • João Moreno (@joaomoreno)
  • Johannes Rieken (@jrieken)
  • Kai Maetzel (@kieferrm) 
  • Martin Aeschlimann (@aeschli)
  • Peng Lyu (@rebornix)
  • Pine (@octref)
  • Ramya Rao (@ramya-rao-a)
  • roblourens
  • Sandeep Somavarapu (@sandy081)
• Acknowledge pull requests in release notes. We acknowledge PRs from outside the team.
  Use the thankyou utility to create the initial version Benjamin Pasero (@bpasero)
  • alexandrudima
  • Andre Weinand (@weinand)
  • Benjamin Pasero (@bpasero) 
  • Christof Marti (@chrmarti)
  • Daniel Imms (@Tyriar)
  • Dirk Bäumer (@dbaeumer)
  • Erich Gamma (@egamma)
  • Isidor Nikolic (@isidorn) 
  • João Moreno (@joaomoreno)
  • Johannes Rieken (@jrieken)
  • Kai Maetzel (@kieferrm) 
  • Martin Aeschlimann (@aeschli)
  • Peng Lyu (@rebornix)
  • Pine (@octref)
  • Ramya Rao (@ramya-rao-a)
  • roblourens
  • Sandeep Somavarapu (@sandy081)
• Mention notable fixes in the release notes:
  • alexandrudima
  • Andre Weinand (@weinand)
  • Benjamin Pasero (@bpasero) 
  • Christof Marti (@chrmarti)
  • Daniel Imms (@Tyriar)
  • Dirk Bäumer (@dbaeumer)
  • Erich Gamma (@egamma)
  • Isidor Nikolic (@isidorn) 
  • João Moreno (@joaomoreno)
  • Johannes Rieken (@jrieken)
  • Kai Maetzel (@kieferrm) 
  • Martin Aeschlimann (@aeschli)
  • Peng Lyu (@rebornix)
  • Pine (@octref)
  • Ramya Rao (@ramya-rao-a)
  • roblourens
  • Sandeep Somavarapu (@sandy081)
• Smoketest
  • Windows - Benjamin Pasero (@bpasero)
  • OS X - Isidor Nikolic (@isidorn)
  • Linux - João Moreno (@joaomoreno)

Friday/Monday

• When done fixing/verifying and there are changes since last build at the end of day PT
  • Trigger new insider build and publish it manually Benjamin Pasero (@bpasero)
• Pause scheduled insider builds Benjamin Pasero (@bpasero)
• Branch code to `release/<x.y> Benjamin Pasero (@bpasero)
• Announce master is open for business Benjamin Pasero (@bpasero)
• Polish release notes Greg Van Liew (@gregvanl)

Wednesday

• Publish Insider with hand-picked and reviewed candidate fixes Benjamin Pasero (@bpasero)
• Smoketest
  • Windows - Chris Martin (@chmarti)
  • OS X - roblourens
  • Linux - Daniel Imms (@Tyriar)

Thursday/Monday

• Build stable for all platforms Benjamin Pasero (@bpasero)
• Sanity check of installable bits
  • Windows
    • signed installer Benjamin Pasero (@bpasero)
    • zip Benjamin Pasero (@bpasero)
  • OS X - Benjamin Pasero (@bpasero)
  • Linux
    • deb package 32-bit Daniel Imms (@Tyriar)
    • deb package 64-bit Benjamin Pasero (@bpasero)
    • rpm package 64-bit Daniel Imms (@Tyriar)
    • rpm package 32-bit Daniel Imms (@Tyriar)
    • archives Benjamin Pasero (@bpasero)
• Publish website Greg Van Liew (@gregvanl)
• Release stable Benjamin Pasero (@bpasero)
• Add a git tag to HEAD of release/1.7 in format 1.7.z Benjamin Pasero (@bpasero)
• Twitter announcement Chris Dias (@chrisdias)
• Enable scheduled insider builds Benjamin Pasero (@bpasero)

Plan Items

We are now using the new Project support to track the work planned for October.

The columns in the project mean:

• Backlog - the backlog for the iteration
• Planned to Start Current week - the work planned to start in the current week of the iteration
• In Progress - the item is actively being worked on
• Done - the work item is done and there is a corresponding test plan item.

[mi-hol]

Currently the github 'projects' page shows 'no due date'.
Community member are hence a bit in the dark about planned time lines and few will find this plan as its 'flagged' as issue. For another project I saw this type of information made visible via 'milestones' https://github.com/serverless/serverless/milestone/15
Hence I wonder if the dates published above would fit better on a 'milestones' page?

[egamma]

mi-hol thanks for your feedback, the example link you provide below is not accessible to me.

Here is how I think about it:

• we still use milestones on issues for when we plan to deliver an item. Milestones have a due date (it was an oversight to not assign a milestone date for October).
• we use 'Projects' to track the progress on these issues we plan for October, i.e., Planned this week, in progress, done, deferred).
• we use Cards in projects for for things that are under discussion and haven't hardened yet as issues.

Bottom line if you are not interested in the progress on an Issue as an external user, then you can just looks at the milestone of the issue and you can also look at the milestones page. However, the milestone page get difficult to digest when it has over 100 items. See the October Milestone as an example.

[mi-hol]

Erich Gamma (@egamma) thanks for your fast response. I've verified the supplied link and it doesn't work when clicked inside the issue for me either but copied into a browser it does. Weird that the link inside a GitHub issue doesn't work (maybe a GitHub bug). URL: https://github.com/serverless/serverless/milestone/15

• Assigning a due date was addressing my comment (note: 'November 2016' milestone lacks it again)

[egamma]

Closing 1.7 has shipped

[mrmlnc]

Hello, Erich Gamma (@egamma),

Small clarification: VS Code team has plans to publish recovery release? Because now we have broken support JavaScript React (#14962) and Less/SCSS comments (#15013).

[egamma]

Denis Malinochkin (@mrmlnc) thanks for pointing this out, added these issues as candidates to the October recovery build.