[chef-dev] Re: Re: Community contribution check-in

[Zac Stevens < >]

The cookbook collaboration workflow is most important to me, too, and
the status quo isn't great.  I feel like it's best to treat the
cookbook site (and the "knife cookbook site" workflow) as a means of
obtaining decent sample code - not as a reliable source of
well-tested, well-supported cookbooks.

I'm not bothered by the fact that a number of the available cookbooks
have rough edges, or have limited platform support ("all the world's
ubuntu" being the chief problem here), but it's immensely frustrating
to be unable to easily help improve the situation.

Sample problem:
 1) Grab the chef_handler cookbook with "knife cookbook site install
chef_handler"
 2) Add this to the run_list for an OS X (or BSD) node
 3) Discover it fails, as the default recipe assumes the root group is
called 'admin'

Fixing my local copy of the cookbook to chose a platform-appropriate
group is a tiny change.  The workflow for submitting the fix upstream
is not at all obvious.  I've got as far as figuring that it involves
forking the entire Opscode cookbooks repo, copying the change from my
chef-repo to my fork of the cookbooks repo, then... something.
Creating a ticket for the fix and pointing at my fork, I guess?

That's a tenable proposition when the fix is a few lines in a single
file, but the effort involved in corralling more complicated
fixes/enhancements is discouraging.

Am I missing something blindingly obvious here?

The general problem holds for cookbooks sourced from elsewhere.  The
"knife-github-cookbooks" plugin gave me a little hope on that front,
it doesn't appear to help with the upstream workflow either.

I'm prepared to accept that I may have the wrong set of expectations
concerning the cookbooks on the community site (Opscode maintained and
other).  I want to believe that they are generally useful, and should
(over time) be able to satisfy common use cases out-of-the-box,
without significant local changes.

I harbour no illusions about the challenges involved in producing
reusable, composable cookbooks, and I don't think we're likely to
clear them without effective collaboration by people working in the
field.  With the friction in the current collaboration workflow, that
doesn't feel especially likely.


To balance the gloom with a little cheer, the weekly triage is
fantastic improvement.  I look forward to receiving the triage
updates, and read them top to bottom - they're a great way of keeping
track of what has been happening, and what to expect.  I ashamedly
note that I haven't submitted any fixes for inclusion as yet, so I
can't comment on the process past submission - but from the outside,
it seems fair and transparent.

tl;dr - things seem pretty good from the point they make it into
Opscode, but the bit before that could be improved.


Zac

On Fri, Aug 19, 2011 at 7:26 PM, Alex Soto 
<
 >
 wrote:
> Cookbook publishing/collaboration is most important to me.
>
> Community Site:
> Just ran into this today.  I happened to look at the cookbook community 
> site and noticed someone posted a comment offering patches 5 months ago!  
> It would have been great if there were some sort of alert to comments.  Who 
> knows if he will notice I posted a comment reply to him.
>
>
> Cookbook Publishing:
> Also, I haven't been actively doing any chef work for the last few months 
> so I might have missed any new developments, but I don't see a good way to 
> publish a single cookbook and easily collaborate on it with someone (pull 
> in patches) and still easily pull it into production chef repositories.
>
> The cookbooks I've published to the community site have all been extracted 
> from my employer's cookbook repository.  I haven't had the time to extract 
> the cookbooks out into public repo's and don't see a simple way to do that 
> without a bit of extra work on my part.  Maybe that's the price I pay for 
> publishing the cookbook, but I'm short on time (like everyone else), but 
> maybe the smoother the process can be, the more the community can 
> contribute?
>
>
> Alex
>
>
> On Aug 18, 2011, at 6:56 PM, Bryan McLellan wrote:
>
>> Hey folks,
>>
>> I'd like to take a minute to check-in with everyone on how the
>> contribution process is working. We've made great strides in some
>> areas, here is where we've been focusing:
>>
>> * Weekly triage to ensure patches get marked for merging
>> * More discussion on this list where everyone can participate
>> * Move toward more regular releases of projects
>> * Increased focus on packaging for releases
>>
>> Here are a couple issues we're looking at tackling next:
>>
>> * Github 'issues' is still enabled for some projects, causing confusion
>> * Pull requests aren't triaged to ensure they have a corresponding ticket
>> * Some projects still need more regular merging and releases
>> * We don't have an automated infrastructure to test releases and cookbooks
>>
>> What is most important to you?
>> Was the contribution process [1] too difficult to pick up?
>> Are there tools we should be utilizing to make it much easier?
>> Any other ways we could improve the experience?
>>
>> Let me know, you can email me directly at 
>> <
 >
>>  if you
>> have any thoughts or concerns that you would be uncomfortable
>> publishing to the list.
>>
>> --
>> Bryan McLellan | opscode | senior systems administrator
>> (c) 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org
>>
>> [1] http://wiki.opscode.com/display/chef/How+to+Contribute
>
>