FWIW, we could set some error status on the affected agent (so users can
see there's a problem) and make it return 0 (so that upstart doesn't keep
hammering it); but as jam points out that's not helpful when it's a
transient error. I'd suggest retrying a few times, with some delay between
Along the same lines, I've been using goimports (
https://github.com/bradfitz/goimports).
Micheal pointed to it. It wraps go fmt and supports the same flags, but
also adds a layer that removes and adds imports that are unused or needed
respectively. I've had good luck with it running on save with
Although goimports is a great tool (I use it all the time) it doesn't implement
the same import grouping rules that we use, or change any existing groups.
I'm tempted to submit a change to it that does
that, but I don't know how well it would be received.
On 15 July 2014 13:20, Wayne Witzel
Yeah, I use it along side of sortimports. Looking at the source for
goimports, I think it would be a clean entry point to add sorting to it. I
imagine a pull request of that nature would be well received by the project.
On Tue, Jul 15, 2014 at 9:19 AM, roger peppe roger.pe...@canonical.com
I don't think we need to stop the world to get these things fixed. It is
the responsibility of the team leads to make sure someone's actively
working on fixes for regressions. If they're not getting fixed, it's our
fault. We should have one of the team leads pick up the regression and
assign
If we aren't stopping the line when our CI is in the red, then what is the
point of even having CI at all? If we are not prepared to adjust the
culture of our development. To truly halt forward progress in favor of
chasing down regressions then I struggle to find the benefit that CI and
testing is
On Tue, Jul 15, 2014 at 2:51 PM, Wayne Witzel wayne.wit...@canonical.com
wrote:
If we aren't stopping the line when our CI is in the red, then what is the
point of even having CI at all? If we are not prepared to adjust the
culture of our development. To truly halt forward progress in favor of
Based on feedback from Rick Harding, amongst others,
we have made some changes to the proposed charm
store API. The new document is here:
https://docs.google.com/a/canonical.com/document/d/1TgRA7jW_mmXoKH3JiwBbtPvQu7WiM6XMrz1wSrhTMXw
The most significant change is that all endpoints
refer just
I think that's a fair assessment.
Perhaps the easiest fix is to install a switch QA could throw to change the
required merge message to something like !!ThisFixesCI!!
On Tue, Jul 15, 2014 at 9:57 AM, William Reade william.re...@canonical.com
wrote:
On Tue, Jul 15, 2014 at 2:51 PM, Wayne
On Tue, Jul 15, 2014 at 1:29 AM, John Meinel j...@arbash-meinel.com wrote:
It seems worthy to just run go test github.com/juju/... as our CI testing,
isn't it? (i.e., run all unit tests across all packages that we write on all
platforms), rather than *just* github.com/juju/juju.
Ah!. That
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-07-15 10:17 AM, roger peppe wrote:
The most significant change is that all endpoints refer just to a
single charm or bundle, rather than being bulk calls as they were
before.
That sounds like the opposite of what juju-reports wants. Does it
My concern was with the speed of response. I'm happy to have a QA Team
switch that must be fixed (with an associated email to juju - dev so
everyone knows why their patch won't land). I *would* like us to be
tracking stuff like how long we go into regression mode, etc.
I think ideally the process
On Tue, 15 Jul 2014, Aaron Bentley wrote:
On 14-07-15 10:17 AM, roger peppe wrote:
The most significant change is that all endpoints refer just to a
single charm or bundle, rather than being bulk calls as they were
before.
That sounds like the opposite of what juju-reports wants. Does
On 14/07/14 09:43, Ian Booth wrote:
Hi all
So last week we had a Juju induction sprint for Tanzanite and Moonstone teams to
welcome Eric and Katherine to the Juju fold. Following is a summary of some key
outcomes from the sprint that are relevant to others working on Juju (we also
did other
On 16/07/14 01:57, William Reade wrote:
On Tue, Jul 15, 2014 at 2:51 PM, Wayne Witzel
wayne.wit...@canonical.com mailto:wayne.wit...@canonical.com wrote:
If we aren't stopping the line when our CI is in the red, then what
is the point of even having CI at all? If we are not prepared
On Tue, 15 Jul 2014, Aaron Bentley wrote:
I am surprised that juju-reports was not considered a known client. I
certainly made many comments on the first draft of the original proposal.
It is listed under known clients in the spec, and we mentioned your request
down below. What we lack is
OK - points taken.
So taking your ideas and extending them a little, I'm thinking:
- retry upgrade steps on failure (with inter-attempt delay)
- indicate when there's upgrade problems by setting the machine agent
status
- if despite the retries the upgrade won't complete, report this
17 matches
Mail list logo
