Meteor issues are growing - how is MDG prioritizing?


#1

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:
    (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?

#2

Note that a lot of those issues are:

  1. Feature requests
  2. Low priority bugs that only affect a small set of people
  3. 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.


#3

@gsabran,

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.


#4

There’s now a roadmap here - https://github.com/meteor/meteor/blob/master/Roadmap.md

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.


#5

Yes I still need to fix some opened issues with the webpack integration and I’m discussing with @benoitt who is doing amazing work.