-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4.09.2014 00:54, David Cheney wrote:
I think this is needless busy work, I vote that as long as there is
a copyright header with _a_ year, that is sufficient.
+100
Let's not do that please, it's pointless.
On Thu, Sep 4, 2014 at 7:50 AM,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As we're on copyright headers topic, is there a clear policy what
headers to use for contributed code, like the one Joyent did or
CloudSigma ?
Should it be:
// Copyright 2014 Canonical Ltd.
// Copyright 2014 CONTRIBUTOR-XYZ..
// Licensed under the
a) As long as we are consistent, Copyright lines don't conflict. The only
chance they do is if you have one long lived branch, and a file was created
in 2012, in one long lived branch it gets updated in 2013, and then in the
other it is updated again in 2014 and then you merge that long lived
...
Have I mentioned how much I hate YAML? Is it possible to write the config
in JSON or something instead? JSON's no picnic either, but at least it
doesn't care about white space. I'd recommend TOML, but I doubt the
conservative dev-ops people would go for it. Ideally we'd support
On 4 September 2014 14:26, John Meinel j...@arbash-meinel.com wrote:
Deploying a local charm is needlessly complex. Why do I need to create a
special directory structure, move my code under there, set --repository and
write local:foo and even then it has to go scanning through the directory,
...
The only sane way I see is for the charm to declare what series it
supports, probably in its metadata.yaml. In practice, we regularly
deploy branches targetted to precise to trusty and vice versa because
one branch supports both series and the branch on the other series
just an
On 4 September 2014 16:30, John Meinel j...@arbash-meinel.com wrote:
...
The only sane way I see is for the charm to declare what series it
supports, probably in its metadata.yaml. In practice, we regularly
deploy branches targetted to precise to trusty and vice versa because
one branch
Hey all,
I've been diagnosing some replicaset issues that particularly show up on
systems with slow disks, particularly our CI infrastructure. To simulate
a slow disk I've been using nbd (Network block device [1]), with
trickle. This provides a remote mounted disk (actually local served
over
On Wed, Sep 3, 2014 at 11:37 PM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
On Thu, Sep 4, 2014 at 3:46 AM, Eric Snow eric.s...@canonical.com wrote:
Here's a write-up on my experience writing a charm for the first time.
Thanks for writing this up.
Blame Nate! He had the sense to ask
On 01/09/2014, Matthew Williams matthew.willi...@canonical.com wrote:
Thanks Martin, yeah things have come up since it tried to land, I'll try
again later today and let you know if there are any problems
Your workaround of making a new pull request was fine. Underlying
issue is the github
The main problem with this approach is the fact that there are still
dependencies between the packages that are not fulfilled.
Mainly because the package name has been changed from gocheck to check, I get
lots of type errors when updating dependencies by themselves.
What works so far is
On Thu, Sep 4, 2014 at 3:26 AM, John Meinel j...@arbash-meinel.com wrote:
...
At the very least we need to know what OS Series the charm is targeting.
Which is currently only inferred from the path. I don't particularly like
it, and I think the code that searches your whole repository and then
given that we currently use the path, you can't have one charm for multiple
series anyway. This would at least be better than what we have right now,
and would be backwards compatible (older jujus would just require the old
style local deploy and would ignore the extra series specification in the
On Thu, Sep 4, 2014 at 3:26 AM, John Meinel j...@arbash-meinel.com wrote:
...
Have I mentioned how much I hate YAML? Is it possible to write the
config in JSON or something instead? JSON's no picnic either, but at least
it doesn't care about white space. I'd recommend TOML, but I doubt
On Fri, Sep 5, 2014 at 5:04 AM, Nate Finch nate.fi...@canonical.com wrote:
given that we currently use the path, you can't have one charm for multiple
series anyway.
For deploying local: charms, symlinks work fine here.
This would at least be better than what we have right now,
and would be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
juju-core 1.20.7
A new stable release of Juju, juju-core 1.20.7, is now available.
This release replaces 1.20.6.
juju-core 1.20.7 is available for utopic and backported to earlier
series in the following PPA:
So it isnt the name change per say, even if they were the same name you'd
get type errors due to a different import path.
It doesn't matter if they all land at the same time. All of the
dependencies can be updated and the test suites should pass in all of their
trunks. In juju-core we won't have
17 matches
Mail list logo
