That's excellent context, Joseph, thanks. I'm convinced. Daniel, I agree
it would probably lead to confusion for folks showing up that aren't from
chef.
Thanks for speaking up!
Onwards!
-ben
On Wed, Mar 5, 2014 at 2:33 PM, Joseph Holsten <jos...@josephholsten.com>wrote:
> 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
>
>
------------------------------------------------------------------------------
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
