Change of emphasis for a couple of weeks

[KevinRansom]

Folks,

The F# OSS community has gone great guns making hundreds of high quality contributions to the F# OSS codebase and Visual FSharp Tools over the last several months. The new IDE tools provided by the community are nothing short of phenomenal. We thank you all for this work, our gratitude is immense.

The Managed Languages Team is entering the end-game for shipping the next release of our tools. The purpose of this endgame is to manage the risk that a code change may introduce significant issues in the VS experience of our tools without time to detect and fix it before shipping. I can assure you … you will be frustrated by it … I always am.

We have already accepted the last RC3 PR and in two weeks we will be at Division Wide escrow, the bar for getting a PR accepted into escrow is very high for example ‘a bug fix to a significant data loss bug that may occur in an easily discovered scenario’ or regressions in compiler behavior causing breaking changes

For the next two weeks the bar looks like this:

• ‘Urgency now’ Bug fixes to existing compiler or IDE features: [RTM] – bug title
• New features to the compiler or IDE: [Update1] – Bug title.
• Perf improvements / reliability improvements
• Significant improvements [RTM] – bug title
• Minor improvementss [Update1] – bug title

Please hold off on Update 1 PR’s for a while, because we will not be doing much to validate it until we enter escrow and I would prefer not to have a big divergence until we are confident what we are shipping is of the highest quality we can manage. If you submit Update 1 PR’s please be prepared to accept that they are a low priority for verification and merge for the next few weeks

Branches:

The F# branch names currently are as follows:

GitHub branch (public)	Release Target
master	                VS2017 (Update 1)
vs2017-rc3	        VS2017 RC3
vs2017-rtm	        VS2017 RTM

In general target your PR’s to master, we will cherry-pick into RC3 and RTM.

Once again, thank you for the outstanding work over the last 18 months, especially the fantastic efforts to produce a new IDE experience, we are so very proud of all of the work done by the F# OSS community.

The F# Team.

[vasily-kirichenko]

IMHO, all of the following commits should be cherry picked to RC3 branch:

Not doing that means:

• no colored quick info / signature help with glyphs
• no working lexer cache
• no working F1
• bugs in Navigation Bar
• bugs in syntax highlighting
• inconsistent coloring between editor and quick info / signature help

(it's all obvious of course, I'm just expressing my fears about cutting those from RC3, which does not look right).

[forki]

Yes definitely. What about the crash on last line? That fix is also not merged yet, right?

[vasily-kirichenko]

@forki It's fixed, but the lexer cache was broken (or it was always broken). "fix-lexer-cache" fixes both bugs.

[abelbraaksma]

Would this be the right moment to go back to all open issues (or even the closed ones) and close them, if fixed, and label them with a label that indicates in which public version a fix will be available (VS2017, F# 4.1?). The ones that have not been fixed in the current release could perhaps get a label "post-vs2017" or something. I have the feeling quite a few are fixed that aren't closed.

This may not be trivial (as in: rather arduous), but as a regular reporter of bugs, I find it hard to find out whether some are resolved or not. This is understandable, often bugs get resolved and it isn't immediately clear it resolves other related bugs as well. By trying to repro existing bug reports in the new VS2017 branch we get a "clean slate" for post-VS2017 and at the same time help any visitors and reporters by having them feeling involved by giving feedback on the state of their bug reports.

If others feel this is worth its while, I can participate in trying to repro (old) still-open bug reports.

[cartermp]

I like the idea of classifying which release a bug gets fixed in. Could be something I can take a look at.

[abelbraaksma]

@cartermp, it looks like there used to be some use of the Git Milestones, like F# Update 1. However checking F# Update 2, F# Update 3 and more recently VS 2017 RTM shows that (apart from Upd 1) this feature has been under-used at best.

It's a pity, because it helps with at least three things:

1. Shows the status of open TODO's
2. Feedback to bug reporters and other OSS volunteers of status and the like
3. Organization (clarity of what goes where).

I would suggest to add a milestone "Later" in addition to what we already have. The Urgency-Later labels are not useful for this, as they are used for priority indication, but don't indicate when something gets resolved.

[cartermp]

@abelbraaksma that's good feedback. I'll go through and classify issues with milestones. I don't have the time to go through the whole backlog right now, but I can classify:

• Recent issues
• Issues related to VS Tooling
• Issues related to .NET Core
• Issues related to F# 4.1

It may not be exhaustive, but it should put a dent in it.

[cartermp]

@abelbraaksma I was able to spend some time going through some of the more recent ones and assigning milestones. I should be able to spend a bit more time in the next few days going through a bit deeper. I think a lot has been covered, though.

[saul]

Appreciate adding the milestones @cartermp - just wondering whether anyone in the F# team has time to assign labels to these 27 untriaged issues?
https://github.com/Microsoft/visualfsharp/issues?q=is%3Aopen+is%3Aissue+no%3Alabel

I understand it's a very busy time for you.

[KevinRansom]

@saul

Done ....

[saul]

Thanks for that 👍 ... I think I added a new issue just as you finished, sorry!

[saul]

Can this be deleted now?

[cartermp]

@saul Not deleted, but probably worth closing.