Is IR being maintained any longer? #1348

Closed
avalanche1 opened this Issue May 16, 2015 · 16 comments

Comments

Projects
None yet
9 participants
@avalanche1

latest release half a year ago, 240 open issues... some announcement from project authors maybe?

@gabrielhpugliese

This comment has been minimized.

Show comment
Hide comment
@gabrielhpugliese

gabrielhpugliese May 16, 2015

  • 865 commits on devel branch
  • 22 branches
  • 53 contributors (including big players from community)
  • 150k downloads
  • Last commit on devel was 18 days ago

I don't think something that big can die so easily.

  • 865 commits on devel branch
  • 22 branches
  • 53 contributors (including big players from community)
  • 150k downloads
  • Last commit on devel was 18 days ago

I don't think something that big can die so easily.

@copleykj

This comment has been minimized.

Show comment
Hide comment
@copleykj

copleykj May 17, 2015

Yeah, I think this is really just a time issue. It's something that most FOSS projects suffer from, especially the smaller ones.. It takes money to free developers time from their other paid commitments.

Yeah, I think this is really just a time issue. It's something that most FOSS projects suffer from, especially the smaller ones.. It takes money to free developers time from their other paid commitments.

@vladshcherbin

This comment has been minimized.

Show comment
Hide comment
@vladshcherbin

vladshcherbin May 18, 2015

We will all migrate to Flow Router, the same thing happened to Meteor Router before IR.

We will all migrate to Flow Router, the same thing happened to Meteor Router before IR.

@gabrielhpugliese

This comment has been minimized.

Show comment
Hide comment
@gabrielhpugliese

gabrielhpugliese May 18, 2015

That would be very sad, again. Meteor Router was very little when that happened.

That would be very sad, again. Meteor Router was very little when that happened.

@dandv

This comment has been minimized.

Show comment
Hide comment
@dandv

dandv May 27, 2015

Contributor

#1219 suggests the IR team no longer has time to actively review PRs :(

Contributor

dandv commented May 27, 2015

#1219 suggests the IR team no longer has time to actively review PRs :(

@allanlundhansen

This comment has been minimized.

Show comment
Hide comment
@allanlundhansen

allanlundhansen May 29, 2015

@cmather I understand and appreciate the challenges regarding time management of ressources between open source and a company, that being said I do believe (even with regards to your business that from my understanding relates quite a bit to the development community) it would be prudent with an update... Just any kind... To the community that also could be potential customers and referrals to your business.

@cmather I understand and appreciate the challenges regarding time management of ressources between open source and a company, that being said I do believe (even with regards to your business that from my understanding relates quite a bit to the development community) it would be prudent with an update... Just any kind... To the community that also could be potential customers and referrals to your business.

@cmather

This comment has been minimized.

Show comment
Hide comment
@cmather

cmather May 29, 2015

Contributor

I'll post an update and plans soon.

On May 29, 2015, at 4:58 AM, Allan Lund Hansen notifications@github.com wrote:

@cmather I understand and appreciate the challenges regarding time management of ressources between open source and a company, that being said I do believe (even with regards to your business that from my understanding relates quite a bit to the development community) it would be prudent with an update... Just any kind... To the community that also could be potential customers and referrals to your business.


Reply to this email directly or view it on GitHub.

Contributor

cmather commented May 29, 2015

I'll post an update and plans soon.

On May 29, 2015, at 4:58 AM, Allan Lund Hansen notifications@github.com wrote:

@cmather I understand and appreciate the challenges regarding time management of ressources between open source and a company, that being said I do believe (even with regards to your business that from my understanding relates quite a bit to the development community) it would be prudent with an update... Just any kind... To the community that also could be potential customers and referrals to your business.


Reply to this email directly or view it on GitHub.

@cmather

This comment has been minimized.

Show comment
Hide comment
@cmather

cmather Jun 1, 2015

Contributor

So the short of it is I'm just under water with teaching and running the EM business, which it turns out is a full time job. I'm very sorry for keeping folks hanging. I feel really bad about it.

I'm putting out a new release in a few minutes that contains a lot of the pull requests. I've been trying to work with MDG Core for a while now to work a router into core (build or integrate) which I think is the right thing to do. I'll write more about that a little later. In the mean time I don't see why starting a router from scratch makes a lot of sense. You can't get much simpler than this:

Router.route('/path/:id', function () {
  this.render('MyTemplate', {data: {someContext: true}});
});

Want things not to be reactive:

Router.route('/path/:id', function () {
  var self = this;
  Tracker.nonreactive(function () {
    self.render('SomeTemplate');
  });
});

The routing package is quite simple. But it's supported by several other packages that were required in order to make it work well with core (dynamic template, dynamic layout, url, location, etc). You can replace any of those layers as desired. It's just a matter of building it.

Contributor

cmather commented Jun 1, 2015

So the short of it is I'm just under water with teaching and running the EM business, which it turns out is a full time job. I'm very sorry for keeping folks hanging. I feel really bad about it.

I'm putting out a new release in a few minutes that contains a lot of the pull requests. I've been trying to work with MDG Core for a while now to work a router into core (build or integrate) which I think is the right thing to do. I'll write more about that a little later. In the mean time I don't see why starting a router from scratch makes a lot of sense. You can't get much simpler than this:

Router.route('/path/:id', function () {
  this.render('MyTemplate', {data: {someContext: true}});
});

Want things not to be reactive:

Router.route('/path/:id', function () {
  var self = this;
  Tracker.nonreactive(function () {
    self.render('SomeTemplate');
  });
});

The routing package is quite simple. But it's supported by several other packages that were required in order to make it work well with core (dynamic template, dynamic layout, url, location, etc). You can replace any of those layers as desired. It's just a matter of building it.

@cmather cmather closed this Jun 1, 2015

@arunoda

This comment has been minimized.

Show comment
Hide comment
@arunoda

arunoda Jun 2, 2015

Contributor

Hi @cmather it's nice to see IR comes back to alive. I can understand the weight you have.

But flow is not to replace IR. We've our own set of rules and how things will be done.
We build our APIs in that way. We help users to write better route code by restricting them into a set of rules and enforcing them via our APIs.

Let me tell me few of these:

No rendering/layout support

Meteor's dynamic templates are great. We enforce users to use it by that restriction

No waitOn

We don't have waiton, so users put that logic into template layer and makes their apps more responsive

No data context (on the router)

Getting data context on the router leads to a lot of re-renders. There are many ways to get around to this problem.

Reactive Apis

We have a sweet reactive API which allows you to get and set stuff to the router. Based on that I've suggested written a blog post: https://meteorhacks.com/meteor-ui-pattern-keeping-app-state-in-the-url

Problmes

The only problem right now is how to handle auth related logic like redirects and so on. We don't allow to use reactive content of middlewares. So, this is kind a tricky right now. So, I'm working on a new project called auth-manager to decouple that from the router and put it into the template layer.


So basically, what I wanted to say IR is pretty good and there are ways to extend that. People could use it in the right way or wrong way(still subjective). But we enforce users to do in the right way.

In the mean time I don't see why starting a router from scratch makes a lot of sense

I don't agree with this. We couldn't experiment with above stuff if we've haven't started from the root. You should not think IR will be the only routing solution we should have. Having more solution helps developers. Specially, since we are not a copy cat of IR.

Contributor

arunoda commented Jun 2, 2015

Hi @cmather it's nice to see IR comes back to alive. I can understand the weight you have.

But flow is not to replace IR. We've our own set of rules and how things will be done.
We build our APIs in that way. We help users to write better route code by restricting them into a set of rules and enforcing them via our APIs.

Let me tell me few of these:

No rendering/layout support

Meteor's dynamic templates are great. We enforce users to use it by that restriction

No waitOn

We don't have waiton, so users put that logic into template layer and makes their apps more responsive

No data context (on the router)

Getting data context on the router leads to a lot of re-renders. There are many ways to get around to this problem.

Reactive Apis

We have a sweet reactive API which allows you to get and set stuff to the router. Based on that I've suggested written a blog post: https://meteorhacks.com/meteor-ui-pattern-keeping-app-state-in-the-url

Problmes

The only problem right now is how to handle auth related logic like redirects and so on. We don't allow to use reactive content of middlewares. So, this is kind a tricky right now. So, I'm working on a new project called auth-manager to decouple that from the router and put it into the template layer.


So basically, what I wanted to say IR is pretty good and there are ways to extend that. People could use it in the right way or wrong way(still subjective). But we enforce users to do in the right way.

In the mean time I don't see why starting a router from scratch makes a lot of sense

I don't agree with this. We couldn't experiment with above stuff if we've haven't started from the root. You should not think IR will be the only routing solution we should have. Having more solution helps developers. Specially, since we are not a copy cat of IR.

@avalanche1

This comment has been minimized.

Show comment
Hide comment
@avalanche1

avalanche1 Jun 2, 2015

@cmather, Why don't you release IR maintenance into full community support if you don't have time for it? I mean authorize a group of volunteers to merge PRs, respond to issues and so forth?
You could announce it on forums.meteor.com, for example - i assume there will be quite a few willing to take over.

@cmather, Why don't you release IR maintenance into full community support if you don't have time for it? I mean authorize a group of volunteers to merge PRs, respond to issues and so forth?
You could announce it on forums.meteor.com, for example - i assume there will be quite a few willing to take over.

@SachaG

This comment has been minimized.

Show comment
Hide comment
@SachaG

SachaG Jun 3, 2015

Contributor

@avalanche1 what's preventing people from doing all that right now? I don't think @cmather is preventing anybody from responding to issues? And if you're willing to take time to learn IR inside out so you can properly test and merge PRs, I don't think Chris would object to that either :)

Contributor

SachaG commented Jun 3, 2015

@avalanche1 what's preventing people from doing all that right now? I don't think @cmather is preventing anybody from responding to issues? And if you're willing to take time to learn IR inside out so you can properly test and merge PRs, I don't think Chris would object to that either :)

@arunoda

This comment has been minimized.

Show comment
Hide comment
@arunoda

arunoda Jun 3, 2015

Contributor

I agree with @SachaG. Maintaining a such an important project is not simple. Someone might send a PR for a one fix. That may lead to ton of other issues. So, it's not simply as taking this over to someone else.

There should be one person overlooking the whole process. And that's hard and time consuming.
Automated tests and can helps a lot, still not 100% sure until you get request from real use cases.

Contributor

arunoda commented Jun 3, 2015

I agree with @SachaG. Maintaining a such an important project is not simple. Someone might send a PR for a one fix. That may lead to ton of other issues. So, it's not simply as taking this over to someone else.

There should be one person overlooking the whole process. And that's hard and time consuming.
Automated tests and can helps a lot, still not 100% sure until you get request from real use cases.

@gabrielhpugliese

This comment has been minimized.

Show comment
Hide comment
@gabrielhpugliese

gabrielhpugliese Jun 3, 2015

I think what prevents it is that he is the only owner of the organization

image

I think what prevents it is that he is the only owner of the organization

image

@arunoda

This comment has been minimized.

Show comment
Hide comment
@arunoda

arunoda Jun 3, 2015

Contributor

I don't think so.
What is really happening is in GH organzations, users need to expose them to the public. Otherwise they are hidden :)

Contributor

arunoda commented Jun 3, 2015

I don't think so.
What is really happening is in GH organzations, users need to expose them to the public. Otherwise they are hidden :)

@gabrielhpugliese

This comment has been minimized.

Show comment
Hide comment
@gabrielhpugliese

gabrielhpugliese Jun 3, 2015

Oh I see :) Sorry!

On Tue, Jun 2, 2015 at 10:43 PM Arunoda Susiripala notifications@github.com
wrote:

I don't think so. There are many, including me.
What is really happening is in GH organzations, users need to expose them
to the public. Otherwise they are hidden :)


Reply to this email directly or view it on GitHub
#1348 (comment)
.

Oh I see :) Sorry!

On Tue, Jun 2, 2015 at 10:43 PM Arunoda Susiripala notifications@github.com
wrote:

I don't think so. There are many, including me.
What is really happening is in GH organzations, users need to expose them
to the public. Otherwise they are hidden :)


Reply to this email directly or view it on GitHub
#1348 (comment)
.

@avalanche1

This comment has been minimized.

Show comment
Hide comment
@avalanche1

avalanche1 Jun 3, 2015

Why don't expand project owners list with trusted ppl who are willing and have the time and the ability to devote to prj development? I saw some PR not being merged for 3+ months. That's hardly motivating to submit further PRs when ur previous ones are not being merged.

Why don't expand project owners list with trusted ppl who are willing and have the time and the ability to devote to prj development? I saw some PR not being merged for 3+ months. That's hardly motivating to submit further PRs when ur previous ones are not being merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment