On 02/18/2015 03:44 PM, Rafael Schloming wrote:
I can't speak to the logic, but I believe the use of contrib to signal pretty much *exactly* what we are talking about here is a pretty common convention. There's a post here that describes django.contrib in much the same terms:http://jacobian.org/writing/what-is-django-contrib/
I think that post describes the criteria for accepting something into the 'blessed' contrib namespace. They don't describe why they called it contrib. They describe it as 'extra, optional, tools' or in the link above 'optional, de facto standard implementations of common patterns'.
So extras or indeed optional would seem equally appropriate and to me, less confusing.
If we didn't already use the contrib convention I wouldn't actually care all that much, but I feel like we should at least be consistent within our own codebase, so if we introduce python.extras, that's pretty much pushing for a rename of the java contrib stuff which seems like unnecessary churn at this point.
I don't think that is the same at all. The current contrib structure is a top level directory under which you have proton-jms and proton-hawtdispatch.
I do get the impression that there is possibly an unspoken bias against contrib,
Unspoken? I said quite clearly I don't like it. To me it has no more meaning than say extras or optional, and the actual meaning of the word doesn't in my view match what we are talking about.
i.e. that's just a bucket to stick unwanted contributions, but I really don't think we should view it that way. I think the comments in the post above about it only containing best practices and what not are something we should take to heart.
I very much dislike it. However if you are adamant on that name, would messenger be relocated there also?
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
