Proposal: Move bento under test-kitchen org

[cheeseplus]

As ChefCo isn't directly supporting* bento I propose we move it under the test-kitchen org as that is now community driven. Redirects will stay in place and nothing really changes materially other than the URL for the repo. Boxes artifacts will still be stored under the bento org in Atlas.

Currently the infrastructure that compromises the build infrastructure lives on my desk in Seattle but I will see if I can get Chef to host the build pipeline as we definitely consume these images internally.

*Yes I work for Chef but my support for bento and test-kitchen is purely out of love and on my own time

[cheeseplus]

/cc @yzl @schisamo

[tas50]

👍

[schisamo]

👍

[yzl]

👍

[lamont-granquist]

👎 i don't see this as being terribly useful. test-kitchen left to its own on its own org suffered from a long period of disinterest and neglect. it is very useful to get bento under the chef-rfc maintenance process and get more community involvement, but i don't see how moving it out of the chef org gets it more resources instead of possibly less resources.

[lamont-granquist]

What we did to farm out opscode-cookbooks to the community is widely viewed as having been a failure. I can't think of an example of where we've been successful at spinning off a project into open source and really having it get picked up and maintained long term. The community cookbooks team now views keeping cookbooks in the chef-cookbooks org and just being aggressive with accepting maintainers as the better policy. Since this feeds into TK its also critical to Chef, and we're feeling the pain of not having staffed TK enough. Spinning bento off seems like either it'll just be meaningless (Chef still will be the maintainer of last resort) or else it'll actually be worse since it'll allow Chef to internally neglect it and write it off as a community project that we don't have any responsibility for.

[cheeseplus]

So in the past I'd have been on the same side as @lamont-granquist but as one of the people heavily involved in both getting TK and Bento out of that state that is no longer the case. I've got community folks and others inside of Chef (non-official resources) excited about paying off exactly the the pain you're referencing.

The problem and why I've come around to this way of thinking is several fold:

• ChefCo wasn't a great maintainer of TK - (we) updated only to fix DKs, when it served a customer, and other things in the same vein.
• We ignored the community of TK which is much bigger than just Chef's community
• Bento is now hosted on Atlas semi-properly but even then I haven't been able to pass this back to Release Engineering so the ownership of the pipeline is squarely mine

If TK and/or Bento is critical to ChefCo then ChefCo needs to make that clear with investment, otherwise these belong to the community and moving it out from under "chef" makes this very clear. I also think that bento, as a project, is relatively attached to the hip with TK and it'd be nice to have the same teams across both.

tl;dr I don't agree but for the exact same reasons

[lamont-granquist]

Yes, so I'm consistent in that I think that test-kitchen clearly needs to be moved under the chef org and we need to staff it[*]. Having test-kitchen under its own org either didn't make it "clear" that it was a community project, or else its just a fallacy that the community will necessarily spring up around a community project and healthily maintain it going forwards.

Your arguments also seem identical to all the argument we made about community cookbooks, or at least I can't understand how they're substantially different, and again we widely view that as having failed.

At the very least I'd like to see this put on "pause". Get a lot of maintainers to sign up and get lots of external committers with commit bits. Once it proves itself to be healthy and maintaining itself without needing central guidance and development from Chef, and the bulk of the maintainers want to move it out, THEN lets move it out.

[*] And I'm aware of the issue where people feel there's some kind of conflict of interest with test-kitchen and Chef because test-kitchen has provisioners for Puppet, but while that's might be Noble, I just reject that as being misguided and and order of magnitude worse for the project. I really think Chef needs to drive TK, because nothing much happened when we neglected it...

[cheeseplus]

I care less who owns it officially so long as it's cared for properly which has not been the case. I feel you on the cookbooks angle but the narrowness of use cases has helped limit the scope to not suffer from the same issues (imo).

I don't think the conflict of interest is a real thing but having done some conf chatting there are many more ansible and puppet users who'd be helpful contributors regardless. We're signaling that in other ways such as planning to make shell the default provisioner and breaking the chef provisioner out as it's own gem/plugin (for technical/maint reasons more than ownership).

We're already adding maintainers and I'm fine with the pause - the change was more symbolic than anything.

[sethvargo]

Hey everyone,

I don't have a ton of time to weigh in on the issue at length, but I tend to agree with most of @lamont-granquist's points. We are starting to get more maintainers and more interested folks in the project, so I would personally prefer to let that pan out for a few months before making too many changes all at once 😄

[cheeseplus]

Closing as per above.