[chef] Re: Centralized cookbook-library repos vs distributed cookbook repos

[Mark V < >]

Aplologies for the top post - I should have said this at the outset.
It is worth stating explicitly:
Having cookbooks as first class repos makes it easier to maintain,
merge and distribute them.

It is not axiomatic that there will be one 'reference' cookbook.  That
is up to the individuals involved.

For some applications there may only be one cookbook in existence.
For other applications 20 cookbooks could coalesce to 3, or 1, or 19.
It will be up to you.
Where recipes are merged into a cookbook it will possible to describe
the 'what-and-why' in one place.
It will be easier to observe how many people are following (github
specific) and contributing to each of the cookbooks.

Regards

On Fri, Apr 9, 2010 at 5:30 PM, Hedge Hog 
<
 >
 wrote:
> Hi ,
>
> Over the last few days I have been lightly using some Chef cookbooks.
> One issue I have run into, even at this early stage, is tracking what
> is going on among the various github 'cookbook library' repositories.
> While it is early days, these cookbook-library repo's are already
> impressive. The large fork count actually seems to be the problem. I
> find it next to impossible to see who has made what changes to
> cookbook Y.
> I also find it nigh impossible to see just how some of the cookbooks
> differ between libraries.
>
> I am wondering why git submodules are not used by the community?
>
> The Chef user base is large enough that there would seem to be enough
> benefits to justify the additional git commands.  Besides, rake tasks
> could take some of the pain out of tracking, updating and contrbuting
> back.
>
> If there was a cookbook account on github with multiple collaborators,
> each application/service cookbook could have its own project under
> this account.
> It would also be possible for more people to volunteer to maintain a
> 'reference' cookbook for their favourite application, using their own
> Github account, and have this as a submodule of a community
> cookbook-library.
> Everyone else could track these individual cookbook projects as a
> submodule of their own 'cookbook-library' project.
>
> To my mind the benefits to each cookbook becoming a first class Git
> project would be:
>  - More applications have one reference cookbook with several
> site-cookbooks to accomdate/illustrate different
> approaches/requirements.
>  - Easily track what people have forked over in a specific cookbook.
>  - Users can pick and choose specific cookbooks rather than taking all
> of several monolithic library repo's of 80+ cookbooks.
>  - Whenever required each cookbook can be tagged with a Chef/Ruby/OS
> version and submodules then point to just that tag.
>  - Settling on a common naming prefix, say 'cc-' (Chef Cookbook), we
> could readily search google and github for these types of projects.
>
> I'm not a Git or Chef guru so I am wondering if I have overlooked somthing?
>
> Regards
>
> --
> πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
> [The fox knows many things, but the hedgehog knows one big thing.]
>  Archilochus, Greek poet (c. 680 BC – c. 645 BC)
> http://wiki.hedgehogshiatus.com
>