More careful management of development

[nicksloan]

Our states are broken at the moment because of some of the recent updates to this formula. Obviously this is not ideal.

I propose that in-development changes should probably be done on a separate branch until they can be properly vetted and tested more thoroughly.

Additionally, we're going to update our config files to depend on a fork of this repo so that updates have to be merged in by us manually. This is probably a good practice in general.

[gravyboat]

Generally we advise users against referencing the formulas directly because as you said they can break some environments (we're all unpaid volunteers so catching all the edge cases can be problematic). The general workflow is that you would fork the repo and treat what you know as working as your master, then merge changes to the formula into some sort of development or test branch to confirm they work in your environment.

Regarding in-development changes this formula has some support for test kitchen. I'd love to merge in more PRs that are related to getting the formulas automatically tested on different architectures and with older pillar configurations and the like. We typically merge PRs that are good for the formula (in this case recently it was more configurable users for running your postgres commands, always a good thing) but sadly this does sometimes negatively impact users or break backwards compatibility.

I'm happy to discuss any of these concerns further if you feel as though you have a good solution for this. Unfortunately creating more branches within the formula isn't really feasible. It's already difficult to keep up with managing all the formula repos and the associated PRs (as I said most of the people who review issues/PRs and do merges are unpaid volunteers) so adding more branches on to that and having to review some PRs twice to get them merged and tested is an additional time sink that many people won't be into (I know I wouldn't).

[nicksloan]

@gravyboat Thanks for the response. Yeah, I was thinking about some of these things myself after I posted that, and I agree that I don't want to create a burden for contributors that would potentially drive them away.

Maybe the contributor-friendly approach would be to simply duplicate this message from the docs in the README.md: "We strongly recommend forking a formula repository into your own GitHub account to avoid unexpected changes to your infrastructure."

This is the sort of thing you can easily forget after reading that page the first time, and despite the bolded text, it doesn't really even jump out at you on that page. I'd love to start a movement to put that text (or some adaptation of it) in the README's of all of the formulas in this organization. I'd love to hear feedback on that idea. It seems like a simple solution that could likely help a lot of people avoid making this mistake.

[gravyboat]

@nicksloan Putting that line into the readme would be a good addition. I THINK a few people have done that for a repo here and there, but it definitely isn't in all of them. The only thing that might be good to add is a link on how to fork GitHub repos. If you want to contribute that or urge others to do so feel free! I know I would be happy to merge this sort of improvement, and I'm sure others would as well.