search

MeteorCommunity / discussions

Track technical discussions in the Meteor community
89 stars 7 forks source link

Should we make a community fork of Meteor? #44

Open mitar opened 9 years ago

mitar commented 9 years ago

Meteor provides now a way to maintain a Meteor fork through meteor publish-release command. We should maybe create a fork which would be compatible upstream, but provide additional APIs which would help develop better packages and features. (Sometimes it is just enough to make something private a public interface, to be able to innovate.)

That could be a good because community could try out the API and code and then once satisfied with a particular change, we could ask Meteor to pull it into the core.

raix commented 9 years ago

@mitar I've been thinking the same thing - when I did the bower release of meteor I wondered why they made the feature and been thinking that its a potentially dangerous feature. One could easily make a aws code deploy version of meteor + looking at the node community Im not 100% sure about forks.

I think it would be a good thing if meant as a friendly convergens to core - it could speed up evolution - but it should be seen as positive thing.

mitar commented 9 years ago

I wondered why they made the feature and been thinking that its a potentially dangerous feature

Easier it is to fork a project, less it will happen. :-)

I thought about it as purely positive thing. It would help determine what is really necessary to go into the core and minimize changes there, but also provide easy way for us who want to live on the edge to have something to work with.

raix commented 9 years ago

I would agree with the edge thing - I guess if we isolated all the extra features on branches it would make it easier to maintain and to make pull - requests perhaps. If forking, it should be managed in some way making it easy to maintain and stable.

mitar commented 9 years ago

The question about fork is: can you depend with a package on a fork. And if you do, does this force the whole app then to use that fork? If this is so, this would be a simple way to see what packages/features need a fork and which not, and users might not even notice that they are using a fork because they chose some package.

dandv commented 9 years ago

@mitar, would you like to add in the OP a list of features that would differentiate the fork? Basically it would be a combo of the issues you've raised within the last day, + things from the Meteor roadmap that the community actually wants, but can't create in the roadmap.

mitar commented 9 years ago

Oh, I don't know which exactly features should go there. But I was thinking more of a process. There is a known fork, with a known repository, where you can make a pull request, and things go in after community decides to do it. We could even use something like votebot for community to vote which pull requests get in.

The idea is that there is something in place. If I want to make a fork now for myself, it takes some time, I have to keep it updated, etc. If we would have one central one we could collaborate.

raix commented 9 years ago

Surgestions for a fork:

mitar commented 9 years ago

Can you make a link to a ticket for each of those, so that we can have discussion there about the content of the proposals themselves? (I have not seen few of them mentioned before and I would love to discuss it a bit.)

raix commented 9 years ago

Updated issue references

mquandalle commented 9 years ago

As you could imagine, I've also been thinking about this possibility. Meteor-core is too slow to accept community contributions (for instance https://github.com/meteor/meteor/pull/2386), and they don't share a lot of their work (eg most of their design document drafts on hackpad are private).

I've been considering joining MDG to contribute more actively to the framework (but I don't know if they want me anyway). Another possibility for me would be to contribute to a meteor community edition, but if we go on that way, we need to clarify our objectives and governance. Are we doing this fork because we're not happy with MDG, or we are happy with it but we just want to do some experiments (and breaks things)? What would be our criteria to accept new features? Do we keep the MIT license? How do we recruit contributors (do we reward them)? What is our release process?

Here is a list of features I would be interested in (in no particular order):

So that's a lot of work, and I think I'm not the only one interested in all of these features. I just need to think more in what the most efficient way to get them could be (taking into account that we have a great community).

rbabayoff commented 9 years ago

Hey, I've been playing with easily basing a custom release using meteor publish-release on an existing meteor version. I can help on that front. I mentioned the current problem of doing this here:

https://groups.google.com/forum/#!searchin/meteor-core/ronen$20babayoff/meteor-core/dhPfUUjYokU/fkkezq0QxrsJ

raix commented 9 years ago

Hi @rbabayoff I think I read your post when I did the meteor bower release - its about the only docs on it - thanks :)

arunoda commented 9 years ago

Hmm. I'm not happy with a fork at this stage. Here's the reason. This is still a very small community and we don't need some divergence. I believe some of these features can be implement as packages.

So, this is what I suggest.

@mquandalle why not contact them and apply for work at MDG :)

rgoomar commented 9 years ago

I agree with @arunoda. I think it makes more sense to be somewhat involved with MDG.

raix commented 9 years ago

@arunoda I'm not 100% about a fork either - I agree that it would be nice if the community and MDG communicated / coordinated more about these things - but thats not the case yet, right?

zimme commented 9 years ago

I feel that a community fork is the absolute last resort if MDG becomes unreasonable for whatever reason

raix commented 9 years ago

@zimme It depends on the purpose of the fork - as @mitar mentioned he wants it to be a positive thing helping us and mdg explore patterns and features - this could boost evolution.

If on the other hand the purpose is like in the node.js example - I would vote against - mdg is a bunch of reasonable people.

awatson1978 commented 9 years ago

I'll chime in with also having thought about a fork or custom track. Specifically a stable version with complete testing coverage for FDA and CCHIT certification, and with a suite of packages catering to clinical application development. (A rough outline is at http://clinical.meteor.com/)

I think it's important to distinguish between track and fork. Most everything that @raix and @mquandalle suggest can be done in a track. A fork would suggest something even more low-level... such as a fundamental change in the Meteor tool or in Atmosphere. For instance, if the community really wanted to go back to a GitHub based package manager, I could see that as being a thorny enough issue that it might warrant a fork instead of a track.

So, I think I'm with @arunoda on this one. Fork as a last resort, and explore tracks in the meantime.

Sivli-Embir commented 9 years ago

I feel like a community fork could cause more problems then it would solve. Thus far almost everything can be solved at the package level. That said I could see a fork for better/pluggable CLI and package settings/environments. Personally it has caused me a lot of grief not to be able to specify where a package goes.

queso commented 9 years ago

Pretty sure a pluggable CLI is on their list, but feature requests are welcome now :)

raix commented 9 years ago

@Kestanous I actually think everything could be solved at a package level if the build tool allowed it :)

Sivli-Embir commented 9 years ago

if the build tool allowed it ~@raix

And thus the only remaining reasons I could see a fork. I am in no rush for better CLI so if MDG is on it then I can wait. Overall IMO I don't think we should fork.