[chef] Re: Re: RE: Re: Re: Re: Re: Re: [RFC] github.com/cookbooks

[Mark Van De Vyver < >]

On Fri, Nov 16, 2012 at 7:21 AM, Peter Donald 
<
 >
 wrote:
> Hi,
>
> On Thu, Nov 15, 2012 at 3:32 PM, Matt Ray 
> <
 >
>  wrote:
>> I think if we (Opscode) and all other producers of Community cookbooks were
>> to tag every uploaded version this would be a moot point but it hasn't
>> happened. I'm sure we're open to suggestions for how to enforce this,
>> especially in the case where Community cookbooks might not be originating
>> from GitHub or even git repos (gasp). Can we somehow make the Community 
>> site
>> support this without creating yet another place to find cookbooks?
>
> I have been using chef for just over a year, created several
> cookbooks, some of which are up on the community site and some which
> are not and the community site is never the site I visit when I want
> to find a new cookbook. The reason for this?
> (1) often the /best/ variants of a particular cookbook are not on the
> community site.

This, and cases of solitary cookbooks, encapsulates 99% of the
motivation of gh/cookbooks and cookbooks.io.
We needed a way to rely on these in development _and_ production.

> (2) often people don't upload the latest cookbook to community site
> (3) inspecting the cookbooks is better done on github rather than on
> community site. Easy to view code, easy to see how many people
> interact with project etc.
> (4) We merge in git repositories into our main infrastructure repo
> (currently through braid [1], probably soon to be with git subtree
> [2])
>
> In my perfect world with rainbows and unicorns, the community site
> would become the definitive source of cookbooks.

We don't aim to be the definitive site. We do hope to offer che-solo
or users of librarian a way to manage the source site as best suits
them.
We are not there yet but that is where we are heading.  It is the
opposite of having a definitive site.
Rather you have a Cheffile that is definitive for that project.
Different Cheffiles could point to different sites, or not. However
you wish to work.

> Every cookbook would
> be stored in some public source code repository that allows you to do
> the dedicated source code browsing/reviewing/inspecting. The community
> site would monitor the source code repository and any time an
> appropriate tag is added would auto-release into the community. To

This is something like what gh/cookbooks does in the background.
It is tricky, but is worth persevering with because it allowed us to
generate cookbooks.io archives that went from 4GB to 20MB.
We haven't perfected this process yet.

> enable this the developer would need to designate a "stable" branch in
> their source code repository of choice and whenever a tag is added to
> that branch this is identified as an appropriate tag and a release
> occurs.

We try to tag the most recent/last appearance of a 'version' in the
metadata.rb|json files.

> The community site also have namespaces so there can be
> multiple cookbooks with the same name. The community site would also
> stop having these crappy tools to view the source and what not and
> instead cross link extensively with the tools like in github. Each
> Cookbook page could link to source viewer, the issue tracker, the
> project page etc. If we ever have a standardised test infrastructure
> we could also upload the test report to the cookbook site.
>
> So the above would allow anyone who wanted to publish a cookbook to
> publish it easily. What it doesn't do is often significant enough
> motivation to make it THE place to put the cookbooks. I don't know the

I think people should be encouraged to develop where ever thay find it
comfortable/enjoyable.
While a Github user might say that the community site is duplicating
Github, and in a way that doesn't suit them, a non-Github user
probably finds it all valuable.
What I do _not_ ever want is to have only one source of cookbooks for
production delpoyments.
In that use case the more site duplicates the safer.
For some people its enough to deploy from git repos, in our case we
wanted a lean, stable source (no expanding git history, nor vanishing
git repo), hence gh/cookbooks+cookbooks.io

Regards
Mark

> best way to do that. Maybe making it possible to generate awesome
> documentation (or at least some documentation) - maybe via the chefdoc
> style tool I have ranted about in the past. If the community site had
> awesome documentation and all the cookbooks I may wat to use it would
> suddenly become a lot more interesting.
>
> [1] https://github.com/evilchelu/braid/wiki
> [2] 
> https://github.com/gitster/git/blob/634392b26275fe5436c0ea131bc89b46476aa4ae/contrib/subtree/git-subtree.txt
>
> --
> Cheers,
>
> Peter Donald