The repo-name/cookbook-name parity is mostly found in cookbooks maintained by orgs who maintain many cookbooks (opscode, heavywater, onehealth, customink). Most independent cookbooks used the style chef-foo, though I personally prefer foo-cookbook (I prefer to reserve chef-foo for plugins).
Here are a small number of repos we use today that use the chef-foo pattern: lusis/chef-logstash edelight/chef-mongodb cgriego/chef-airbrake_handler fnichol/chef-rvm Here's some examples of cookbooks maintained by the actual project: basho/riak-chef-cookbook elasticsearch/cookbook-elasticsearch stackforge/cookbook-openstack-compute On 2014-03-05, at 19:29, Ben Hartshorne <gang...@green.hartshorne.net> wrote: > Hi folks, > > The process towards the ganglia team having ownership over the default > ganglia chef cookbook is proceeding well. I have a dilemma I'd like your > help solving. > > There is a strong preference in the Chef community towards having the name of > the github repo containing a cookbook be the same as the name of the > cookbook, as well as a strong preference towards having the name of a > cookbook being the same as the name of the software it configures. > > For example, the popular web server nginx is configured by a cookbook named > nginx in a repository named nginx: > https://github.com/opscode-cookbooks/nginx. This extends so far as to assert > that when downloading the cookbook from the community site directly (eg > http://community.opscode.com/cookbooks/nginx) the directory in the tarball > must be named the same as the cookbook. When organizing your chef cookbooks, > they live in a directory structure that matches the name of the cookbooks; eg > chef/cookbooks/nginx/. > > This doesn't mix terribly well with organizations that host cookbooks for > configuring their own product. The elasticsearch folks, for example, buck > this trend and name the repository cookbook-elasticsearch. While some tools > understand this, at other times you have to manually rename it to just > 'elasticsearch' (the name of the cookbook) before you can use it. > > It's understandable why they did this thing, if you go to > http://github.com/elasticsearch/elasticsearch, what you find is the actual > elasticsearch product. This makes perfect sense, and is what you would > expect when you come at it from the perspective of some random person looking > at github. > > My dilemma: from the perspective of a chef user, we should name the > repository 'ganglia'. From the perspective of github, we should name it > 'ganglia-cookbook' (or its current name, 'chef-ganglia'). > > We're in the unique position that this choice is not forced; we don't > currently have a repository named 'ganglia', since the main ganglia codebase > lives in monitor-core. > > If the repo name was the only piece of information presented to a person > browsing repositories on github, the choice would be much simpler. The > presence of the repo byline ("A chef cookbook for installing and configuring > ganglia") makes it pretty clear what the repo contains regardless of its > name. This byline makes it reasonable to me to name the repo just 'ganglia' > instead of 'ganglia-cookbook' or something like that. > > So, who's got opinions? > > Please vote! Weak/Strong Support/Oppose/Don't Care: > * ganglia > * chef-ganglia > * ganglia-cookbook > * write-in alternative > > -ben > ------------------------------------------------------------------------------ > Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. > With Perforce, you get hassle-free workflows. Merge that actually works. > Faster operations. Version large binaries. Built-in WAN optimization and the > freedom to use Git, Perforce or both. Make the move to Perforce. > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk_______________________________________________ > Ganglia-developers mailing list > Ganglia-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ganglia-developers
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
