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


Chronological Thread 
  • From: AJ Christensen < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: [RFC] github.com/cookbooks
  • Date: Thu, 15 Nov 2012 10:22:55 +1100

I really don't like this. I've always been worried about our (Heavy Water) cookbooks being mirrored and used from this "organization"; users identifying faults and then not having the information to get in contact with the original author/maintainer.

Are you guys just trying to be involved with the community? What's the real "value add" here? What's up with the bogus stance on Berkshelf? I can see how a big cookbooks org might have been useful before the community converged around dedicated cookbook organizations with one-cookbook-per-repo, e.g.:

https://github.com/opscode-cookbooks
https://github.com/hw-cookbooks
https://github.com/salsita-cookbooks
https://github.com/dreamhost-cookbooks
https://github.com/sethvargo-cookbooks

https://github.com/search?q=cookbooks&type=Users

Are there overwhelming issues with the Opscode Community cookbook site that haven't been resolved, that lead you to want to spend Cold Hard Cash money developing and operating www.cookbooks.io

Are you going to put ads up on the site to cover bandwidth costs?

Community is hard, let's go ride bikes.

--AJ


On 15 November 2012 09:39, Mark Van De Vyver < " target="_blank"> > wrote:
Hi Alex, 
Thanks for the feedback. I'll also try address your concerns/questions in the blog post.  
Two quick clarifications: 
 - We don't use Berkshelf but will happily entertain suggestions for www.cookbooks.io that make Berkshelf integration easier.  
 - github.com/cookbooks is the opposite of one big repository. Each cookbook has its own repo, and the account/organization tracks multiple vendors/indiviudals cookbooks.

Regards
Mark


On Wed, Nov 14, 2012 at 8:31 PM, Alex Howells < " target="_blank"> > wrote:
On 14 Nov 2012, at 04:13, " " target="_blank"> " < " target="_blank"> > wrote:

> Initial TODO is (essentially based on the roadmap stated in cookbooks/about):
> - extract tar.gz and zip archives of each repo's tags to www.cookbooks.io
> (delivered by the AWS ClouFront CDN)

Is this sustainable? I'm all for people and companies chipping in with
solutions, but as RubyGems knows this quickly becomes a $10000+ per
month bandwidth bill. Who's footing it and what happens when one day,
someone says "Wow that's a lot of money, how do we cut back in this
bit of the budget?" - what about all the users who're now relying on
it?

> - write a source for librarian-chef to retrieve archives from www.cookbooks.io

Don't forget Berkshelf!

> - regularize updating of github.com/cookbooks

As Noah said, I'm not sure what the logic behind one big repository is
now. Whilst I understand and accept folks have used this in the past,
is the effort worth it for the future?
>


Is there anything newer or better about the updates shipping here?
More cookbooks covered with test-kitchen or some other "nice to have"?





Archive powered by MHonArc 2.6.16.

§