How open source Meteor really is if pull requests are not getting in?

ctaloi · February 6, 2016, 12:47am

FreeSwitch has been doing this for years, weekly call that is then released in a podcast feed. I’m sure the community would help with the logistics, I know I would.

manuel · February 6, 2016, 12:49am

I don’t know how feasible it would be to implement in our case, but Microsoft has a system where everyone has a certain number of points (10 I think) and they can use it to “vote” for the issues and features they like best. The points replenish every so often.

debergalis · February 6, 2016, 1:36am

I’d be happy to come on.

Steve · February 6, 2016, 9:10am

I would advise against reinventing the wheel here. Open source release management is a particular field, with quite complex processes. I think Meteor needs some more expertise.

laosb · February 6, 2016, 11:08am

So it seems that we’re going to have a foundation. That sounds good! What I would suggest there is an detailed solution on that.

We can have a Technology Committee, which includes community people and MDG guys in a 1:1 ratio. The community half can be elected by community and the MDG half contains every or a part of MDG, which is decided by MDG. The TC have write acess to the repo, shares the rights. Whenever there is a PR, the TC decides it.

nathan_muir · February 6, 2016, 3:00pm

Wow. I’m finding it hard to find a positive comment worth leaving.

@mitar I think your comments have been 100% on-point. None of the reasons given thus far are adequate to hold back community involvement. It’s simply laziness & lack of incentivisation to incorporate the community.

Personally, I’m at a crossroads;

On one hand, I think community involvement is crucial to provide necessary maintenance to the meteor v1 series.

On the other hand, If we don’t get cooperation, I’m happy enough to maintain a private fork; & start preparing my codebases for various components to become “End-of-life”.

mitar · February 6, 2016, 9:37pm

Just to add a bit more oil to the fire, for example this pull request: https://github.com/meteor/meteor/pull/5968

It is a bugfix. It comes with tests. And it clearly made many people have issue with it: https://github.com/meteor/meteor/issues/3427

This pull request adds a feature: https://github.com/meteor/meteor/pull/6008

Comes with documentation, tests, backwards compatibility, and also interest from the community: https://github.com/meteor/meteor/issues/2730

My question is: why such pull requests cannot be merged in faster? Why such pull requests could not be reviewed by the community and merged in by the community? Yes, the feature request adds some maintenance, but it also solves concrete needs people have.

Just for some food for thought. Why would it be useful to share commit bit.

mitar · February 6, 2016, 9:39pm

Maybe it does not have to be a completely private fork, but we could merge things into one. I think many of us maintain their own forks. We could help each other here.

mitar · February 7, 2016, 10:40pm

Copying from my comment on GitHub:

When you say, “Many features wanted by community was not accepted into node.js.” – do you mean that those same features were accepted into io.js? Can you point to a few examples?

That was the main issue why the fork occurred. Now with merger, those features did get back into the node.js though. You can also notice that they started to increase the version number much quicker now.

io.js FAQ is an useful read: https://iojs.org/en/faq.html

Also: https://github.com/nodejs/node/blob/master/GOVERNANCE.md#readme

Also interesting idea is their approach to long-term support releases: https://github.com/nodejs/LTS/

I think they had very similar issues to what Meteor has: how to combine fast-paced changes and development some want, with stability and production-readiness. (And I know that I am speaking sometimes on both sides of this debate: I would like both long-term stability for some of my projects (like having Blaze around) but also new features in core to try new things in libraries I do.)

About why fork: http://anandmanisankar.com/posts/nodejs-iojs-why-the-fork/ (Compare decline in Meteor commits with graph of decline in node.js commits - here you see what means “features not getting in”. It is even worse at node.js time.)

Features io.js added immediately (and community wanted): new V8 engine, ES6, interface with V8. (I would bring some similarity to how Meteor is still on very old version of underscore. Or node.js engine itself. Or even Mongo - still 2.6?)

See from: https://www.quora.com/Why-is-NodeJS-splitting-into-two-versions-io-js-and-node-js

IOjs is forking NodeJS because of issues with open governance. The main problem is that NodeJS can’t keep up with releases and fixing issues because nobody’s really allowing things to get fixed, it isn’t as open as things claim. Since V8 is coming along, it would be nice to stay on top of the new changes which is the point of IOjs.

sashko · February 8, 2016, 7:21am

What did io.js do about backwards compatibility? Did they just drop it? Would immediately shipping a Meteor 2.0 that doesn’t work with any previously published packages, or any currently developed apps, be a good idea?

mitar · February 8, 2016, 7:54am

They started using semver versioning.

Would immediately shipping a Meteor 2.0 that doesn’t work with any previously published packages, or any currently developed apps, be a good idea?

Any previously published package? Like, no previous package would work? Of course this would not be OK. I do not think anyone is arguing for this. And rare changes really break everything. Of course such changes should be discussed widely and made with a very good design.

But making some smaller feature in 2.0 print deprecation warning and then in 4.0 removing them would probably be OK. Especially if you have a transparent process where even before 2.0 you explain what will become deprecated in 2.0 and people can take part in it.

And we are mostly talking about adding small features community would like to see, not removing them. Like unblock in publish context. We talk about removing just because some argue that we should not accept feature requests because this means maintenance costs will go up to unmanageable levels, or something.

I really think you should look into Django. They have the best approach I have seen. See detailed release notes where you really know how to upgrade anything which changed. It is some work (both for package maintainers and sites), but it is pretty clear what is the process and how to change things.

joshowens · February 8, 2016, 4:49pm

I’m just not sure Transmission is the best place to discuss changing how to work with community on Meteor code. A full subset of the community should be involved in a discussion like this. I did the Q&A back in July with @debergalis and he talked about fixing this stuff, but we haven’t really seen any changes happen. I have a feeling that a conversation limited to two people won’t lead to much insight or real actionable change. My goal is to see actionable change for the betterment of the community.

benstr · February 9, 2016, 2:53am

rgoomar · February 9, 2016, 3:01am

Looks like PRs are getting some more attention. There were quite a few of them merged in today.

nathan_muir · February 12, 2016, 4:31am

@sashko, Just on the idea of bots & automating Issue & PR management; have you taken a look at:

or,

Running these tools on meteor/meteor would be really helpful for cutting down the noise, and surfacing important issues to focus MDG time/effort on.

sashko · February 12, 2016, 4:32am

Holy crap! I was looking everywhere for something like this - a module to help me build custom bots. Could be the start or something great.

nathan_muir · February 12, 2016, 4:36am

Yeah, this example looks super cool -

github.com

fat/haunt/blob/master/examples/basic.js

// BASIC HAUNT EXAMPLES
// ====================

var assert = require('assert');

module.exports = {

    'pull-requests': {

        'should always be made against -wip branches': function (pull) {
            assert.ok(/\-wip$/.test(pull.base.ref))
        },

        'should always be made from feature branches': function (pull) {
            assert.notEqual(pull.head.ref, 'master')
        },

        'should always include a unit test if changing js files': function (pull) {
            var hasJS    = false
            var hasTests = false

This file has been truncated. show original

nathan_muir · February 12, 2016, 4:39am

This might get a bit meta, but if you start work on a bot, it would be cool to make it public, so we can contribute.

(Submitting PR’s to the bot that checks PR’s…)

mitar · February 12, 2016, 6:31am

If you are talking about open sourcing stuff, I would really like to see open sourced their bot for checking signed CLAs.

sashko · May 20, 2016, 6:56pm

2 posts were split to a new topic: GitHub bots for managing issues