search

MeteorPackaging / discussions

Ask for Meteor integration help, or discuss Meteor 3rd party library packaging
5 stars 1 forks source link

How hard should we try to convince the original library author to accept the PR? #5

Open dandv opened 9 years ago

dandv commented 9 years ago

Continuing the discussion from the original thread:

While my stance when I started this effort was that it would be great if original library authors accepted our PT, the practice has shown that most weren't that enthusiastic about the idea.

@splendido proposed to keep the PR very lean; but that limits the usefulness of the integration: we can't add tests, or complex integrations that some packages (see rubaxa:sortable) deserve.

My opinion is that we should build as robust of an integration as we want in the MeteorPackaging org, ping the author about it once it's working well, and if they don't want to accept it, they might as well offer to tweet about it, as the Bootstrap guys have.

If all we need to request is a Webhook, that's fine.

As for submodules vs. forks, forks are easier because we might need to modify the grunt/gulp/make file as part of the publishing process. Also, if the integration requires patching an existing file (though I haven't seen a case where the export file didn't do the job), the fork is better than having to patch the file again after updating the git submodule.

CC @bobiblazeski.

splendido commented 9 years ago

I'm reasoning about even another solution... Let me reason a bit more on it and then I'll show you an example to see what do you guys think about it.

But I agree that we shuold add tests and follow the best practices suggested on MeteorPedia to [deal with exports](http://www.meteorpedia.com/read/Packaging_existing_Libraries#Dealing with exports).

I'll be back in a few hours ;-)

bobiblazeski commented 9 years ago

Just one more thing that comes in my mind. It would be nice to add meteor specific examples for many libraries like d3, nvd3, d3plus etc. Firing the sample meteor application is a very nice plus to see does the package works. I don't know how hard sell will be to authors who don't use meteor.

dandv commented 9 years ago

If we have all Meteor-related files in a meteor directory in the integration branch, I'm not sure why authors would care whether we have tests, demos, or an entire app in there. They could treat meteor as a black box.

Anyway, with regards to examples, check out the tests for the Bootstrap integration. If you copy package.js to the root dir and run meteor test-packages, you'll see in the browser all Bootstrap JavaScript components.

Another, simpler visual test/example - https://github.com/MeteorPackaging/Chart.js/tree/meteor-integration/meteor

bobiblazeski commented 9 years ago

What will happen with MeteorPackaging fork when original author accepts ownership?

splendido commented 9 years ago

in case the fork was only the mean to create the integration PR, there's no reason to keep it polluting the MeteorPackaging space ;-)

...differenlty is we move towards something like what I'm proposing on the other issue, we won't need the PR (if not an issue to ask for the creation of a webhook...) and we'll need to keep the pacakge (not the fork) on MeteorPackaging for obvious reasons...