We used to cherry-pick every commit that had even one card in "To Cherry
Pick", even if it was also referenced by a card in "Rejected" or even
"To Consider".
Now we will warn and skip those commits.
I took this opportunity to add a bit of an object model for servicing
cards as well as prettify the output.
That allowed us to add a list of cards that were ignored due to having
no commits, and display little icons for each type of card.
I thought, "what if I could just have a script make all the releases,
tags and names and upload all the assets to the right place?"
So, here's that script.
It makes the output less cluttered and more correct (for example:
ServicingPipeline no longer tries to service two copies of each commit
if there's a merge in the history...)
New-TerminalStackedChangelog used to generate logs that looked like this:
```
* [3] A commit that was seen 3 times
* A commit that was only seen once
* [2] Some other commit
```
Now it will generate logs that look like this:
```
/ base..branch-1
|/ base..branch-2
||/ base..branch-3
* [XXX] A commit that was seen 3 times
* [ X ] A commit that was only seen once
* [XX ] Some other commit
```
This format is more expressive, as it indicates _which branches_ contain which commits.
As a reminder, my release note writing style starts with a stacked changelog. It's how I tell (1) which commits are in the new preview release only, (2) which commits are in the new preview and the new stable release and (3) which commits were already released in a previous stable release.
Changes from 1 get included in the new changelog, changes from 2 get included in both and changes from 3 get deleted because they have already been released.
```
% .\tools\ReleaseEngineering\ServicingPipeline.ps1
Inferred servicing version 1.14
PICK f025c53dba: Remove the fallback to wsl.exe when HKCU\...\Lxss doesn't exist (#13436)
OK
```
This script takes pull requests from a project board, cherry-picks them,
and updates the project board. It also yells at you if there are
conflicts to resolve, and generally tries to keep track of everything.
It is quite cool.
I've done this process enough times that I should have written a script
to do it a while ago. This one is rough, but the whole changelog process
is pretty rough.
This script takes multiple revision ranges and produces something that
looks like a rough untranslated changelog, with indicators for how many
of the provided ranges had the same change (deduplicated by title.)
I use a process like this to build the Stable and Preview release notes
out of a set of revision ranges.
