I’ve been bumping my head against the wall for a few weeks because Meteor is taking ~1mn to rebuild as soon as I do any kind of file change, as have others: https://github.com/meteor/meteor/issues/4284
So this made me wonder:
how long before I move to another framework where I can get stuff done
what is Meteor “quality” state. Here is a vizualization of the number of issues from https://9-volt.github.io/bug-life:![|689x221](upload://101ltj8bPs8iSzjjTbU00a5tJf6.png)
(This tool seems to count labels, so some issues would get counted several times if they have several labels. Or at least this is how I understand the difference between 1.7k and the 1k issues github reports)
Anyway, issues number is continuously increasing and it’s very high.
So:
are most of those issues not a priority/not super relevant? If so, why?
else, why is MDG focussing on first developing new ambitious features like Apollo before getting issues settled?
Low priority bugs that only affect a small set of people
No longer relevant but it’s hard to tell
We are putting effort into improving issue management, follow along here:
There’s a process underway to define a principled way of dealing with and resolving issues.
Either way, the number of issues in a project isn’t a good metric for anything, just like the number of lines of code isn’t a good metric for how much work is getting done.
Apollo seems to be a critical piece of MDG’s future, so they are investing there. The community is slowly stepping up to take over pieces of Meteor (started with the Blaze repo). Which is a good thing for governance and the future of the framework. Makes everyone happy and safe.
It shows what they’re currently working on/is coming in the near future. I think the build tool was mentioned as a priority during the 1.3 beta but AFAICT, the node update seems to have taken precedence over that.
Until then, @benoit has made webpack integration a lot easier which should help with build times till the build tool gets looked at.