[chef-dev] Re: Re: RFC: Template Verification

Chronological Thread 
  • From: Mike < >
  • To: Daniel DeLeo < >
  • Cc: Steven Danna < >, Chef Dev < >
  • Subject: [chef-dev] Re: Re: RFC: Template Verification
  • Date: Thu, 31 Jul 2014 11:36:04 -0400

> ... “small, backwards compatible features” ...

Isn't one of the goals of RFC procedure to determine the small-ness of the given feature?
I think it might be easy to introduce many small, backwards compat features that eventually become hard to change if the overall vision doesn't map to where the project is desiring to go.

Filling out RFCs for features, not bugfixes, seems reasonable to me, as they widen the visibility and expose the feature to discourse.


On Thu, Jul 31, 2014 at 11:27 AM, Daniel DeLeo < " target="_blank"> > wrote:

On Thursday, July 31, 2014 at 4:57 AM, Steven Danna wrote:

> Ohai Chefs,
> I've posted a small RFC here:
> https://github.com/opscode/chef-rfc/pull/38
> about a feature I'd like to add to Chef.
> This RFC is also interesting to me in terms of the emerging chef-rfc
> process. In the past, I would have proposed a feature this small
> simply as a pull request with the code already written. For small,
> backwards compatible features, is that preferable over an RFC?

I think “small, backwards compatible features” can just be a pull request. In general my thoughts are:

* Anything breaking cookbook DSL compatibility should be an RFC
* For changes to chef-server, we should err on the side of using the RFC process, because there are two implementations maintained by Chef Software and at least one maintained by a third party. Optional features, like node history reporting, which are implemented by Chef Software as paid add-ons are a probable exception (with the stipulation being that chef-client works correctly in the absence of these features).
* Aside from the above, size/scope should be the determining factor. If unsure, you can ask on the mailing list.
* The RFC process shouldn’t be used as a substitute for contributing code. Chef Software is going to prioritize its engineers’ time based on what makes business sense. Even the most excellent ideas are not guaranteed to be prioritized.

> Cheers,
> Steven

Maybe we should write this up as a retroactive “rfc zero” that goes in the README of chef-rfc?

Daniel DeLeo

Archive powered by MHonArc 2.6.16.