So I said I would do some analysis on bugs on the compiler and core packages in order to help inform disucssion around how we can move forward with this. I was thinking I would have time over the xmas holidays, turns out I had even less free time then vs when I am working! Anyway, I now have a spreadsheet organized in a way that enables me to communicate my findings:
I analysed anything people asked me to, plus all the outstanding PRs on core packages and the compiler. It made sense to focus on the PRs since there are less of them than the open Issues, they consist of proposed solutions so I can be precise in understanding how they would affect the overall system, and since someone bothered to make a PR the issue is obviously important to someone as well as possible to fix in a relatively small amount of code.
But… The main reason to focus on PRs is that is where the process gets stuck. You can discuss issues, get help with workarounds, raise github issues, develop solutions. Once something is submitted as a PR it mostly seems to get stuck there - there is no working process to get your contribution into Elm.
How bad is the problem though? How much unmerged good stuff is out there?
I categorised the PRs from the most trivial ones (doc fixes), which have zero affect on the overall system, to the most invasive ones, which affect the semantics of the Elm language itself in ways that break compatability with 0.19. The categories in order of increasing impact are:
- Doc Fixes
- Performance Improvements
- Runtime Bug Fixes
- API Changes to Implementation
- API New Functions
- API Changes
- Language Semantics
It is entirely possible that we could fix things in levels 1 - 4 as a community release branch of Elm without breaking compatability with the official 0.19 release.
Level 5 does not break compatabilty, but new code relying on it would not be able to revert to the official release unaltered.
Levels 6 - 7 break compatability and are heading more in the direction of a fork, as opposed to a release branch.
Counts of number of issues in the sheet given below.
Doc Fixes - 68
Its great to improve the docs and there is plenty good stuff in here. However, fixing the docs is not really what we have in mind when we think of making progress with the issues that are causing us problems.
Performance Improvements - 13
Nice to have perf improvements too.
Runtime Bug Fixes - 11
API Changes to Implementation - 26
These 2 categories are where I thought I would find the most interesting stuff. These are the real bugs in the implementation and they are fixable without breaking things. Generally these fixes are very localised and deal with the rough edges that people have found in the wild.
There are only 37 items in these 2 categories which reflects on the very high quality of Elm 0.19. It is also likely there are more issues that could be fixed in these categories but no PRs have ever been submitted because potential contributors have been put off by the lack of a functioning process.
API New Functions - 19
Worth mentioning the app.kill one, which is a frustrating issue for some people. It might be a bit misclassified here, as its a JS API rather than an Elm one.
API Changes - 2
Language Semantics - 4
Compiler Stuff - 24
I didn’t include compiler PRs in the other categories, since compile time is different to runtime, and preserving compatability of the runtime and language is the primary focus of my analysis.