I think the use of maintainers rather than maintainer would be
appropriate. Would we use it in both instances of a single and multiple
maintainers, check for both when doing a charm proof, have charm proof
set the use of maintainer as opposed to maintainer as a warning that
gets outputted, etc.
Hi all
We've been talking about what we need to do to finalise 1.18, and the issue
with manual bootstrap addresses in environments.yaml [0] has been causing
us some problems; in particular, we think it was a mistake to put the
bootstrap node address in environments.yaml in the first place, and
On Mon, Mar 3, 2014 at 11:54 AM, William Reade
william.re...@canonical.comwrote:
Hi all
We've been talking about what we need to do to finalise 1.18, and the
issue with manual bootstrap addresses in environments.yaml [0] has been
causing us some problems; in particular, we think it was a
In some places, we have exposed constants that should not normally be
public as public variables, purely for the purpose of testing. The reason
we need to do that, is because packages can't use code that is only exposed
in _test files for other packages (i.e. package foo has a export_test.go
John talked to me on a hangout and suggested that, often times, when you
need to expose something like this for tests, it ends up being something
that production code needs to tweak as well. He'd like to see something
better than a public variable, but didn't offer a suggestion as to what.
I
I think this is a huge regression for a lot of people on the devel release.
It means you can have manual provisioning within a cloud, but that you
can't use Kapil's digital ocean plugin, use a pile of servers in your
basement (which don't have good IPMI, and can't run with MAAS), etc.
So, it
On Tue, Mar 4, 2014 at 12:54 AM, William Reade
william.re...@canonical.comwrote:
Hi all
We've been talking about what we need to do to finalise 1.18, and the
issue with manual bootstrap addresses in environments.yaml [0] has been
causing us some problems; in particular, we think it was a
On 04/03/14 15:22, Andrew Wilkins wrote:
On Tue, Mar 4, 2014 at 12:54 AM, William Reade
However, blocking 1.18 on this change would be most unhelpful to
many people, so we would like to simply switch off manual provider
bootstrap for the 1.18 release; this would *not* be a
