Okay, so taking in Sidnei's feedback I've merged this request as it's
reverting back to a previous state. The example not withstanding I'm
curious on how we should handle such changes in the future.
Thanks, Marco
On Mon, Nov 4, 2013 at 10:53 AM, David Ames wrote:
> On 11/03/2013 05:00 PM, Sidne
On 11/03/2013 05:00 PM, Sidnei da Silva wrote:
> To be clear, this *specific* change (the rename of a config.yaml argument)
> is a revert of r31 of the charm in the charm store.
Also in this specific case, nagios_check_http_params is the config key
used in several of the other charms and would be
To be clear, this *specific* change (the rename of a config.yaml argument)
is a revert of r31 of the charm in the charm store.
On Sun, Nov 3, 2013 at 9:50 PM, Marco Ceppi wrote:
> Hi all, I need some consensus on how to handle merge proposals for charms
> in the charm charm store when these prop
Hi all, I need some consensus on how to handle merge proposals for charms
in the charm charm store when these proposals change configuration key
names. The proposal in question is
https://code.launchpad.net/~sidnei/charms/precise/squid-reverseproxy/trunk/+merge/190500
in
the config.yaml diff the fo
