[chef] Re: Cookbook Releases, summit edition


Chronological Thread 
  • From: Hedge Hog < >
  • To:
  • Subject: [chef] Re: Cookbook Releases, summit edition
  • Date: Tue, 6 Dec 2011 06:40:40 +1100

Hi,
For those unaware there is http://github.com/cookbooks ... which
currently has one cookbook per repo.
I'm quite happy to make change to how this account is run.  However,
[why is there always a qualification :)]
 - this account's repos are always open to tracking non-opscode cookbooks
 - who is upstream is a function of quality, so the opscode's repo
does not _have_ to be upstream, but it generally is for the same
reason: quality.
 - we don't 'drop' a repo, it can be dormant if its upstream is dormant.
 - I repos upstream can change, but is always tracked by the `master` branch.
 - contributions are pulled into the `qa` branch and this is the
branch each cookbook team has responsibility for, and ideally is the
branch that people should track, and issue pull requests against.
 - Handling issues, pull requests, and general cookbook housekeeping
is the responsibility of each cookbook's 'team'
 - Up to now team membership has been quite 'open', i.e. if you seem
to know what you are doing with the cookbook (i.e get someone to
second a pull request of yours), and you know how to make a clean pull
request, then youre added to the team.
 - We haven't been swamped by volunteers, so maybe something isn't yet
quite right in the above, although I do ack that the auto updates of
the repos to their upstream has been less frequent than I'd like.
 - Of course team membership can just as easily be revoked.

Having said that [yes another qualification], apart from the first
point, I'm quite open to suggestions about how to proceed.

HTH

On Tue, Dec 6, 2011 at 2:39 AM, Joshua Timberman 
< >
 wrote:
> Ohai!
>
> Last week we had the first Opscode Chef Community Summit in Seattle. A hot 
> topic from that related to cookbooks is whether the project should stay as 
> a single large repository with the 118 cookbooks, or whether they should be 
> split up into separate per-cookbook repositories. The overwhelming majority 
> of people that we talked to were in favor of separate repositories because 
> it makes it easier to contribute, and manage for end-users. This has also 
> been requested over the last couple years since the creation of the 
> cookbooks project in the first place. It will require additional work, 
> workflow documentation and supporting code for us to manage, so please bear 
> with us as we get the repositories ready and released.
>
> With that said, here's the highlights of cookbook releases from the past 
> week or so:
>
> mysql - v1.2.2
>
> * http://tickets.opscode.com/browse/COOK-834 - Add ;'scientific' and 
> 'amazon' platforms to mysql cookbook
> * http://tickets.opscode.com/browse/COOK-826 - mysql::server recipe doesn't 
> quote password string
>
> nginx - v0.99.2
>
> * http://tickets.opscode.com/browse/COOK-772 - Update Nginx source download ;
> location
> * http://tickets.opscode.com/browse/COOK-809 - nginx default access_log ;
> should be disableable
>
> haproxy - v1.0.4
>
> * http://tickets.opscode.com/browse/COOK-806 - haproxy load balancer should ;
> include an SSL option
> * http://tickets.opscode.com/browse/COOK-805 - Fundamental haproxy load ;
> balancer options should be configurable
>
> nagios - v1.0.4
>
> * http://tickets.opscode.com/browse/COOK-838 - Add HTTPS Option to Nagios ;
> Cookbook
>
> --
> Opscode, Inc
> Joshua Timberman, Technical Program Manager
> IRC, Skype, Twitter, Github: jtimberman
>



-- 
πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
[The fox knows many things, but the hedgehog knows one big thing.]
  Archilochus, Greek poet (c. 680 BC – c. 645 BC)
http://hedgehogshiatus.com



Archive powered by MHonArc 2.6.16.

§