Hey @sashko,
I am surprised at the community. Didn’t realize there were so many free-riders 
– before anyone hits, that’s a (kinda’) joke!
So I like your idea of splitting out the packages into a separate repo, and we can be part of that. Things like tracker, pub/sub can in the future go there as well.
Where do we begin?
No need for package server – npm is available and works today, right?
For certain definitions of ‘works’. Personally not a fan of npm.
We will never have what we had before. Npm will have to do.
I’m not sure how more than one person can truly be in control of something, unless you have a very robust voting process or consensus committee for every change. The slowness, I’ll admit, is partially our fault - we’ve been working on making it possible to publish Blaze releases outside of Meteor for a long time, but we’ve finally done it!
As of Meteor 1.4.1, core packages can be updated outside of the release cycle.
This was a pretty big change we made specifically to enable this kind of mini-forking of formerly core parts of Meteor. We were planning on doing a similar thing with Accounts as well, back in the day, but we haven’t found someone to be “in charge” of that section of the code. Perhaps it could be you!
I agree that a lot of work is going towards Apollo now, which is not a minor upgrade to the Meteor livedata system, but instead a “spiritual sequel” - in that, we plan to migrate our internal Meteor apps to this new data system soon, and we think we’ll be better for it, for all of the reasons we mentioned when we started the project - backend independency, easier to tune reactivity, easy joins, and more.
It’s a new feature for Meteor, re-packaged in a way that it can be adopted much more widely, ensuring it doesn’t become “classic” anything.
Someone migrated Meteor to Node 4 - a relatively thankless project extremely important to the future of the platform. Those people put in long hours that aren’t as visible, because it’s not a “hot” new feature, but rather an important and big chunk of serious maintenance work that required reworking some big stuff.
We definitely have the hours to help someone like @ramez move to maintaining a part of the “classic” Meteor codebase, if you want to call it that.
I don’t think there is any world where increased adoption of a community-driven Meteor hurts anyone.
Apollo is an independent project that adds one more choice to the data platform component - it’s not going to contaminate anything. Do you feel like adding React support contaminated Meteor?
Well, the first question is - who should be owning this new repository? Mitar needs no introduction, we’ve all worked with him before and he’s submitted countless patches to the core.
If there is some sort of community consensus about who should hold the keys to publishing new versions of, say, Accounts, then we can certainly make that happen on a very short schedule based on the work done in 1.4.1.
Might be interesting to do a sinopia integration.
I’ve asked a couple times at the Meteor Customer Day and MeteorCamp at the U.N. about what it means to have a release track or distro in the context of NPM. The release-manifest.json is the Atmosphere concept of a release or distro; but NPM doesn’t quite have the same concept… maybe a package.json file. That, in turn, brings up the idea of an application.json file.
The ideal scenario for myself (and many of my clients), would be to have:
package.json would be for NPM of course; application.json would be for Meteor and the build pipelines; and distro.json would be for sinopia servers, local caching of packages, etc.
Thanks for asking. I think it doesn’t because it’s optional – I need npm for React and supporting Meteor integration.
From what I understand, Apollo will be something that’s included, and will add to and modify existing infrastructure, when I do a $ meteor update --release@1.5
It won’t be. So that’s good to clear up!
Oh, wow, this is probably not the right spot, but I’d really like to know now how Apollo will be “integrated” with Meteor. Will it be as simple as a npm install? And will 1.5 then just be Meteor classic with “hooks” of some sort for Apollo?
If this is the case, the implication is from that point you just work on the Apollo as a npm package, with its own independent releases, and Meteor classic becomes a “integration point” for which one can choose to add Apollo and supporting MDG-based npm packages to or not.
@ramez Ultimately I agree with @sashko that it would be best to direct your efforts towards maintaining components/packages within the existing Meteor org. You’ll get more support from us there and have an easier time attracting other community members to help with maintenance because of pure visibility. I think it’s better for the community to have community-driven components easily discoverable within the Meteor org so that we don’t end up with a very fragmented maintenance effort for the pieces of Meteor classic you really care about.
We’ve put a lot of work into making community contributions possible despite some gnarly technical hurdles, but it seems like there still needs to be a clearer process for community members to step in and get involved and/or to let us know what’s getting in their way of doing so. If you’re interested in hashing this out with me and @zoltan, who’s also been working on the contribution process (as documented here) we’d love to get your feedback.
Thanks @thea, really appreciate you reaching out. Absolutely! Want me to PM you on the forum to choose a time for a call with you and @zoltan?
You’ve got it 100% correct!
Bigger discussion here if you want to join in and talk more in depth: Apollo + Meteor: which features exactly are coming in 1.5?
Ah, did that finally ship? Mozel tov! If so, that may make 1.4.1 a bellweather release, similar to 0.6.5.
Heh. Given my experiences trying to contribute in the past to Meteor and Velocity, I think I’ll stick to something a bit smaller than Accounts to begin with. Maybe a PR to Session or Random to see if things have actually changed.
But maybe. I’d rather coordinate with the useraccounts folks than have it just be on my plate (especially since I have grad school starting in a few weeks).
The clinical:active-entry package we’ve been maintaining has additional requirements like 30 minute timeouts and LDAP authentication - features intended for a corporate/clinical environment. And the work we’ve been doing isn’t really aimed at supporting any/all view layers; just Blaze and React. But we were talking about migrating to use useraccounts:core, and if it would mean being able to integrate auth0:lock and LDAP and an OAuth server into an official solution… well, maybe. That would be worth talking about.
This is a great discussion! I just wanted to add some of my thoughts. We absolutely welcome forks and custom release tracks. This is one of the things that makes open source great!
As core maintainers, we have to ensure a very high bar of quality for contributions we accept into core as they will impact everyone in the community. I know this can be frustrating because it puts a lot of emphasis on having long discussions about design, making sure good tests are included and contributions are aligned around the needs of the majority of our users. I think this can give some users an us vs them feeling, like the folks inside the walls of MDG are trying to maintain dictatorial control over the project. This couldn’t be further from the truth!!
We’re actively looking for more external core contributors who share the project’s values around building solid stable software for the majority. You may have noticed @abernix’s heavy participation on the project in recent times. He does not work at MDG.
The other angle here is technical. The current architecture leans towards a central point of control. The release process can only be executed in house and there is package infrastructure that is designed to be maintained in-house. We’re doing our best to refactor the project towards a more open model (e.g moving towards npm and a light release process) to make it easier for the community to maintain and fork. Due to the complexity of the codebase, this is going to take some time so please bear with us (or help out if you love solving difficult problems!).
I also want to re-emphasize that other than transitioning from Node 0.12 to Node 4, we don’t intend to swap out any of the core components of Meteor in 1.5, 1.6, or any other version. The stuff we add is just that: additions that you can safely ignore.
In fact, probably a lot of the fatigue of people who feel like the official materials like the Guide have switched to a more complicated, module-first, choose-your-own-adventure format could probably be helped by collaborating on a new educational resource that describes the “classic” way of doing stuff, with only Blaze, “global” variables, limited NPM use, etc.
This is a relief to hear!
Thank you for brining this up! Will you be opening a clear channel for contributions and clear place to park this within the exiting resources?
Open to ideas! Where would you park it?
Could be a good idea - we could make another copy of the guide/docs themed app, set up CI, and put it on another URL, like classic.meteor.com or something.
I was hoping these anti-MDG posts died with this post