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

Start work on collection:<name> packages #72

Open
zimme opened this issue May 6, 2015 · 18 comments
Open

Start work on collection:<name> packages #72

zimme opened this issue May 6, 2015 · 18 comments

Comments

@zimme
Copy link
Member

zimme commented May 6, 2015

Hey

I've been working with my packages lately and this got me thinking I wanna start renaming some of my packages and I thought about using the collection namespace.

@dandv: Would you mind adding me to the colllection organization as I saw that you were one of the maintainers of it.

This is what I have in mind for my own packages:

  • zimme:collection-behaviours -> collection:behaviours
  • zimme:collection-timestampable -> collection:timestamp
  • zimme:collection-softremovable -> collection:softremove

My upcoming work for archiving docs would go into collection:archive.

I would also like to ask a couple of the other guys if they're willing to join my effort and provide their functionality under the collectiton namespace.

@rclai
lai:collection-extensions -> collection:extensions?
Maybe even collection:core? (this needs more discussion)

@mattb33
matb33:collection-hooks -> collection:hooks?

@dburles
dburles:collection-helpers -> collection:helpers?
dburles:mongo-collection-instances -> collection:instances?

My thoughts around this is that we all try and rely on each others work as much as possible.

I know @dburles already accepted a PR to use lai:collection-extensions, which is nice.
I've also seen @lai doing some work on making @matb33's matb33:collection-hooks rely on lai:collection-extensions.

I myself would rely on his package for collection:behaviours to have the option to automatically add the behaviours to all the collections instead of just manually attaching the behaviours to specific collections, but I feel it should be a choice. There will be a need for supporting an exception list though.
In my packages for specific behaviours like collection:softremove I already rely on matb33:collection-hooks.

We would all be responsible for our own packages under the namespace, but I believe the benefits of us all working more close together are great.

We would make the decision on which "new" packages we would accept into the namespace.

Examples:

  • Once i start working on collection:archive I wouldn't publish the work under the namespace until a majority of us feels its ok to do so.
  • If we get requests from package maintainers to join the namespace we would make that decision together.

I also think we could work out of either the MeteorCommunity or MeteorPackaging organization on Github.
Another alternative is to use one of MeteorCollection, MeteorCollections or MeteorCollective organization which I've just registered. I will remove the unused organizations once a decision has been made.

Who knows, maybe @aldeed want to join us with his aldeed:collection2 package under the name
collection:validation or something in that direction.

I feel that we all could benefit from such an endeavour.

What do you guys think? Do you feel it's worth it?

@mitar
Copy link

mitar commented May 6, 2015

How should we rename PeerDB then? collection:orm? :-)

@zimme
Copy link
Member Author

zimme commented May 6, 2015

Something like that could definitely work. As I mentioned, discussions are needed around which packages should be integrated into the namespace and under what name they will be integrated. 😄

edit: The same goes for my packages ofc

@rclai
Copy link

rclai commented May 6, 2015

This sounds like a good idea.

@matb33
Copy link

matb33 commented May 6, 2015

Count me in. Also, @rclai your fork of collection-hooks that uses your collection-extensions is a great idea -- definitely in for that too.

@rclai
Copy link

rclai commented May 6, 2015

@matb33 I wanted to give you a pull request (even after your tests have passed under it and has been working fine for me), but I'm kind of scared to and don't want other people's stuff to break because of me lol, but maybe this time I will (after I get it synced upstream).

@zimme
Copy link
Member Author

zimme commented May 7, 2015

Nice to see that there's some interest in this 👍

I'm rewriting and renaming zimme:iron-router-active, I'll see how that process plays out.
Hopefully it goes well and the experience from this rename/move can be helpful for us with this endeavour.

I'm pubishing a new package zimme:active-route and then releasing a new version of zimme:iron-router-active which uses and implies zimme:active-route.

It's a shame that Meteor don't have support for renaming packages yet. But maybe it's possible to ask MDG/Percolate Studio to move all the meta data surrounding the packages to the new names.

@aldeed
Copy link

aldeed commented May 7, 2015

I like this idea. Last night @SachaG and I were discussing the need for more of a committee/organization structure around some of the related and oft-used packages (but without giving up too much author control). This could be a good step in that direction for collection packages.

My biggest worry is the transition/renaming. If @zimme can come up with a foolproof plan for that, I'm in. I think MDG's approach to renames of core packages in the past has been keeping the old packages around as empty "imply" packages.

@zimme
Copy link
Member Author

zimme commented May 7, 2015

Yeah, the renaming/moving is quite a concern. I'll keep you guys updated on the renaming of zimme:iron-router-active.

I've already used pretty much the same method when I've integrated Meteor support into the libraries I've wrapped before. vodkabears:vide was zimme:vide and mouse0270:bootstrap-notify was zimme:bootstrap-grown.

With these packages I just published a new version which used and implied the new official packages, updated the READMEs and descriptions to inform developers that they've been deprecated. Then I just meteor admin set-unmigrated <package:name> to hide them.

The big difference from those packages are that I didn't care for the metadata around the packages and here we do.

@SachaG
Copy link

SachaG commented May 7, 2015

Sounds like a great idea. And I'm happy to take PRs to implement these packages in Telescope, that can be a good way to bring more attention to them.

@zimme
Copy link
Member Author

zimme commented May 16, 2015

@dandv, would you consider giving me access to the collection namepsace for this purpose?

I assume you're sitting on the namespace as your Github is linked on it's atmosphere page.

@dburles, I also saw that you were mentioned on the page, do you have access to the namespace?

@mitar
Copy link

mitar commented May 27, 2015

So I was thinking of renaming PeerDB then to collection:odm?

@zimme
Copy link
Member Author

zimme commented Jun 1, 2015

So I just released zimme:active-route@2.0.0. It's zimme:iron-router-active which has been renamed, let's see if it's a recipe for success or disaster.

If all goes well with this rename, hopefully people will be more inclined to join this namespace.

@zimme
Copy link
Member Author

zimme commented Jun 11, 2015

@mitar, unless there are some other "big" packages which do the same thing as peerdb does then I'm all for having peerdb become collection:odm, but if there are other packages which do "the same" I think a discussion around the subject is needed.

@aldeed
Copy link

aldeed commented Jun 12, 2015

I think of the collection: packages being mix-n-match small packages while packages like peerdb and astronomy are a more all-in-one approach. I could be wrong, though.

@zimme
Copy link
Member Author

zimme commented Jun 12, 2015

That is a valid point @aldeed

But where would we draw the line?

@dburles
Copy link

dburles commented Jun 12, 2015

I'm actually not sold on this idea as it seems to conflict with/break the intention of the author/organisation naming convention by now depicting a kind of ‘category’ rather than an organisation, which then raises a bunch of questions. It feels like it's a kind of side-step, given the packaging servers lack of categorisation.

@zimme
Copy link
Member Author

zimme commented Jun 12, 2015

@dburles That's something I hadn't thought about and it's a good point.

I'm open to maybe do this under som other namespace, which is more like an organisation in that sense.

@zimme
Copy link
Member Author

zimme commented Jun 30, 2015

Ok, so from the discussion here and how my effort with renaming zimme:iron-router-active to zimme:active-route has gone, I think we will skip the renaming part of this. @dburles brought up a very valid point about using the collection and general namespaces like this.

When Meteor have support for renaming packages for real the discussion about using a common namespace for our packages might be valid again.

But I think we who maintain these "simple" collection packages which focuses on one thing per package should try and work together as much as possible. I suggest we use this issue tracker here under the MeteorCommunity organization to keep in touch and discuss common problems and/or new ideas.

I'll close this issue in about one week unless the discussion have resurrected.

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

7 participants