Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Utilities namespace #74

Open
zimme opened this issue May 16, 2015 · 8 comments
Open

Utilities namespace #74

zimme opened this issue May 16, 2015 · 8 comments

Comments

@zimme
Copy link
Member

zimme commented May 16, 2015

Hey @SachaG

What's the plan for the utilities namespace?
I see you've published the avatar package under the namespace.
Should we use it for any general purpose utility?

@SachaG
Copy link

SachaG commented May 16, 2015

Yeah, I did. I was hoping to get 2-3 other packages published under the namespace before making any kind of official announcement.

Just to bring people here up to speed: inspired by the talks of a collections organization, I created a utilities organization for things like the avatar package, spinner package, etc.

The problem with names like sacha:spin is that it makes it harder for others to contribute: they won't have publish rights for Atmosphere, so if they want to fork the package and take over they'll have to publish their own myname:spin package, forcing end users to change their code.

So by using the utilities:spin naming, we can ensure that users never have to change the name of the package in their code, and also that there's a small community of trusted developers who all have publish rights on each other's packages.

@zimme
Copy link
Member Author

zimme commented May 17, 2015

Yeah, pretty much in the same lines as I was thinking about the collections namespace.

Just a note. You have the option as a maintainer of a package, say sacha:spin, to add another meteor account as a maintainer to the package under the same name, which makes it possible for another person to publish under that package name.

But still it's a nice initiative, I just hope I'll get access to the collections namespace... otherwise I'll consider using this namespace maybe?

@SachaG
Copy link

SachaG commented May 18, 2015

Oh yeah, I know I can add other maintainers. But the situation that prompted me to create utilities was that the maintainer for a package I use simply stopped answering emails or issues, so he wasn't able to add me.

@zimme
Copy link
Member Author

zimme commented May 18, 2015

Yeah, I get it. I've been there too 😝

So do you have any thoughts on if we're going to try and work out of some Github organization or just from our own repos?

My first thought is that it would be nice to work out if MeteorCommunity or MeteorDevelopmentCommunity or something, I feel MeteorPackaging is more for the 3rd party library effort.

This also relates to #72, where i suggested MeteorCollections. Now with this initiative I feel that working out of a common Github org might me nice.

@zimme
Copy link
Member Author

zimme commented May 18, 2015

I'm also sitting on the mdc namespace, short for Meteor Development Community

@SachaG
Copy link

SachaG commented May 18, 2015

I'm fine either way. A GitHub org would make sense, but I think it'll be easier to start with letting people keep their existing repo if they want to.

@zimme
Copy link
Member Author

zimme commented Jun 30, 2015

So @dburles brought up a very valid point on using general namespaces like this in #72, what are your thoughts on this?

@SachaG
Copy link

SachaG commented Jul 1, 2015

I don't really have much thoughts on his point to be honest. The main problem I'd like to fix is end users having to change their .packages file when the package's maintainer changes.

That doesn't really make any sense to me. I feel like packages should have a unique name, and as a package author I should be able to transfer my package to somebody else without any extra work on the user's part.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants