- 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.