To allow explicit placement for EC2 instances, including Juju
controllers, we could (trivially) implement support for `--to
subnet=` placement (like the existing - and supported - `--to
zone=`).
Then you could do `juju bootstrap ... --to subnet=172.31.5.0/24` (with
or without --config vpc-id=vpc
ions test results will have noted some
> fallout from the initial setup, all of that should now be resolved so
> treat any new failures of maas substrate testing as significant.
>
> Martin
>
Awesome! Thanks Martin! :)
--
Dimiter Naydenov
Juju Core Sapphire team <http://juju.u
t see anything in the 2.5 release notes about fixing behaviour
> on file
> move/rename, though I may well have missed it.
>
> And not being able to deal with really large PRs is a definite issue
> too (not
> that github is better there).
>
> cheers,
&g
✉ reed.obr...@canonical.com <mailto:reed.obr...@canonical.com>
> ✆ 415-562-6797
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com <mailto:Juju-dev@lists.ubuntu.com>
> Modify settings or unsubscribe at:
> https://lists.ubunt
RC, if you need some help how to do that)!
Cheers,
Dimiter
On 08/03/2016 01:17 PM, Dimiter Naydenov wrote:
> Hey James,
>
> Thanks for the detailed information! I think you did find a bug, let me
> try to explain.
>
> First, it looks like your vpc-ff069a98 meets the minimum co
t; Just realizing now, I have been specifying 'vpc-force-id', not
> 'vpc-id-force' (g).
>
> I would expect to see this resolved when I apply the correct
> config. I'll report back shortly.
>
> Thanks for your time!
>
ould be greatly
> appreciated. Are these network spaces ops even supported on aws?
>
> ~thanks
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com <mailto:Juju-dev@lists.ubuntu.com>
> Modify settings or unsubscrib
the _10 minute_ timeout to make this test run.
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
--
Dimiter Naydenov
Juju Core Sapphire team <http://juju.ubuntu.com>
signature.asc
Description: OpenPGP digital signature
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
https://docs.google.com/document/d/1pKORpWSitOk7C_HMNBaO36-Ht1b3lT86bOWTy9jPMDQ/edit?usp=sharing>
>
> Thanks,
> John
> =:->
>
> PS> For James Page and other's that have already looked at this
> document, can you give it a once over. I pulled out some of the
> a
red to
> be an alias. The format is expected to be:
>
> = [...]
>
> So we can do things like:
>
> # stat is like two whole letters shorter... stat = status
> --format=tabular
>
> # list tests list-environments = system environments list-users =
> user lis
f those can
> and should pass through a simple api facade, not just dance off to
> play with the direct-db-access fairies.)
>
> There is no justification for *any* of those things to see a
> *state.State, and I'm going to start treating new workers that
> violate layering
ryl.
>
> Tim
>
Way to go, congrats Cheryl! :)
- --
Dimiter Naydenov
Juju Core Sapphire team <http://juju.ubuntu.com>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJV5XLGAAoJENzxV2TbLzHwyQIIAKdquqyMiquGsqr4l6Q/XF1s
ksf7OpGPUQ4k+Ici3Sw0dUr5sQ
rthcoming retry scheduling logic
> in the storage provisioner. Any objections?
>
> Cheers, Andrew
>
>
I second that.
It looks like it's under active development, so we might want to
vendor it in a subdir of the main repo? Have we decided about how are
we doing vendoring?
Chee
are going to do two things:
>>
>> 1) increase the timeouts for the uniter
>>
>> 2) change the uniter tests
>>
>> WRT to point 2, most of the uniter tests are actually fully
>> functional end to end tests, and should not be run every time we
>> land
ws.vapour.ws/r/2190/diff/#
>
> However I feel there may be a hole now in the KVM networking
> testing.
>
> Can someone who knows what they are doing take a look please?
>
> Cheers, Tim
>
Good catch and thanks for taking care of this Tim!
I've commented on the
to figure out why the result of "go test -race
- -cover" has data races reported, while "go test -race" or "go test
- -cover" for the same tests shows no races at all.
- --
Dimiter Naydenov
Juju Core Sapphi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 22.05.2015 11:07, Andrew Wilkins wrote:
> On Fri, May 22, 2015 at 3:47 PM, Dimiter Naydenov
> <mailto:dimiter.nayde...@canonical.com>> wrote:
>
> On 22.05.2015 08 :26, Andrew Wilkins wrote:
>> Hi all,
>
>>
ng the same for OpenStack for 1.24 also.
>
> Cheers, Andrew
>
>
I assume we won't tag instances with a Name tag if there already is
one, right? Otherwise it's a bad UX.
For OpenStack, we should use instance names the same way (and only if
the name is not already set), as tag
ding of Juju core design and internals.
>
> So let's give praise, thanks (and reviews) to Domas, for a job well
> done!
>
> -Casey
>
>
> -- Juju-dev mailing list Juju-dev@lists.ubuntu.com
> <mailto:Juju-dev@lists.ubuntu.com> Modify settings or un
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 26.03.2015 05:25, Eric Snow wrote:
> On Wed, Mar 25, 2015 at 8:00 PM, Dimiter Naydenov
> wrote:
>> One thing to bear in mind. It seems the europe-west1-a AZ is
>> considered "deprecated" and will be shut down soon (en
ironments.yaml. Obviously this'll be documented, but I
>>>> think it'd be nice if in environments.yaml we could just
>>>> specify the location of the JSON file that GCE spits out,
>>>> and have Juju extract the info it needs, like we do with
>&g
a draft into this document so that we
> can collectively bring this document to a final state
>
- --
Dimiter Naydenov
Juju Core Sapphire team <http://juju.ubuntu.com>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJVBDyKAAoJENzxV2TbLzHwie8H+wZP89uOvhE1hDjLwEqHRflt
LSdAcsbae
id, if there are any packages you think we should *not*
> gate landings on their test suite passing yet, please say now.
>
> Thanks!
>
> Martin
>
- --
Dimiter Naydenov
Juju Core Sapphire team <http://juju.ubuntu.com>
-BEGIN PGP SIGNATURE-
Version: GnuP
gt; build with the trusty toolchain still, and not accidentally let in
> regressions by depending on newer gos.
If it's about catching map ordering issues, let's use go 1.3+ as an
extra step, rather than gccgo, which is buggy and slow and randomly
segfaults. It's likely we'll
ribute the "load" on the
OCRs better.
Cheers,
- --
Dimiter Naydenov
Juju Core Sapphire team <http://juju.ubuntu.com>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJU5xH4AAoJENzxV2TbLzHwLXIH/0bnpQYCv08uvqeBYHteiCHF
t3hDcic3z1qGtrz8OlSdA7uysNc1frCLZXgrWp
soon.
Cheers,
- --
Dimiter Naydenov
Juju Core Sapphire team <http://juju.ubuntu.com>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJU31uiAAoJENzxV2TbLzHw+e4H/RC++f9cNasheO51s5gdVpAo
xBiwsS/eWPVaWl4yNPQfa+y1HQlJwUyE1mTlR3uVET1TE+E+uIwUpoKVWFqqJgsU
rDwgiizUNzZ6PkYllabjLCR04KL2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9.02.2015 22:11, Dimiter Naydenov wrote:
> Awesome job, the new links look great and are very useful! Thank
> you Martin! :)
>
I've noticed the onhover links today and I have a suggestion.
In Firefox I observe some erratic behavior
rather than in a single package used by
> everything. To my mind this is a more modular and scalable
> approach.
>
+1 I like the idea of having state/errors for
sharable-but-domain-specific errors (or network/errors,
storage/errors, etc.) and leave generic errors useful it a lot more
ca
in storage package (or a subpackage thereof
to allow importing without loops), but things that go in state or over
the wire via the API need to be in subpackages of state and params.
>>
>> Cheers, Andrew
>>
>> -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify
feedback on what would be useful to see here.
>
+1 I'd really appreciate this!
> Martin
>
Cheers,
- --
Dimiter Naydenov
Juju Core Sapphire team <http://juju.ubuntu.com>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJU2RR
itional other bridges or VLAN
> sub-interfaces.
>
> I'd like you folk who understand networking more to work out some
> heuristics that will at least get us unblocked.
>
> Cheers, Tim
>
- --
Dimiter Naydenov
Juju Core Sapphire team <http://juju.ubuntu.com>
--
avoided (as for example the exiting
exp/ package - it never got any serious attention or maintenance).
- --
Dimiter Naydenov
juju-core team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJUrtbLAAoJENzxV2TbLzHwUJgH/0MSzjf0siNc1G/w8z+HKRVp
O5YujoXW9qGg7CmkZjlrdOFOh8WBnHXJ+AT0UjG2KifiM5i4ikcGtH+
DOs that we left as we were writing code.
>
> Our branch is at: https://github.com/wwitzel3/juju/tree/ww3-gce
>
> -- Wayne Witzel III wayne.wit...@canonical.com
> <mailto:wayne.wit...@canonical.com>
>
>
Awesome news! Great job guys!
/me now has a reason to get a GCE ac
so
>>>> that's possible. Thoughts?
>>>>
>>>> cheers, Kapil
>>>>
>>>>
>>>>
>>>> -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify
>>>> settings or unsubscribe
ssue no longer blocks merges.
>
> On 19 December 2014 at 09:40, Menno Smits
> mailto:menno.sm...@canonical.com>>
> wrote:
>
> On 19 December 2014 at 06:02, Dimiter Naydenov
> <mailto:dimiter.nayde...@canonical.com>> wrote:
>
> -BEGIN PGP SIGNED MESSAGE
r. This won't normally be a problem as we tend to use pointers
> to document structs with transaction operations, and the panic is a
> helpful indication that the document provided isn't
> multi-environment safe.
>
> No
ture is to
re-queue PRs set for merging but bounced due to a CI block. This
wastes days sometimes, or at the very least hours.
>
>
> Based on experience and observation, I think I know how at least
> some of this works but could we please have some authoritative
> a
z) unable to talk to the API
server (on 10.t.u.v). It was suggested in some forums as Menno
discovered, to add a static route 10.0.0.0 to the API server's local
IP, which fixes the connectivity issues, but it's unknown what's the
impact of that fix otherwise.
- --
Dimiter Naydenov
juju-
goamz users group (https://groups.google.com/forum/#!forum/goamz)
was also notified of the change.
Check out the repository page for links and more information.
Have a nice weekend and enjoy! :)
- --
Dimiter Naydenov
juju-core team
-BEGIN PGP SIGNATU
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19.11.2014 09:12, Dimiter Naydenov wrote:
> On 19.11.2014 02:10, Jesse Meek wrote:
>> I'm coming across double spaces after a full stop in comments.
>> Some consider this an error, others an intentional style that
>> ma
ace. I'll
> tally up votes on Friday and update our style guide accordingly.
>
> My vote: +1
>
- -1, come on isn't this just for typewriters?
- --
Dimiter Naydenov
juju-core team
-BEGIN PGP SIGNATURE-
Version: G
security certificate is not
trusted", so I need to either add an exception or change the URL to
use "http" instead.
2. If you do add an exception try to review and click "Ship It!",
it's not taking effect (Michael had that issue with one of my
reviews). So you *need*
o state management.
>
> :( How will anything get into the release notes if engineers don't
> announce the new feature when it merges? It is not the not release
> note because engineers haven't described it.
>
> Aski
reviews.
>
> Congratulations.
>
>
> Tim
>
Yay, way to go Menno! :)
I think this should encourage other "mentored" reviewers to heed the
call and graduate.
Cheers,
- --
Dimiter Naydenov
juju-core team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBA
suggested, I still think it's
the easiest way to do it correctly. E.g. it could be a new target:
+
+updeps: godeps
+ GOOS=windows $(GOPATH)/bin/godeps -t ./... > dependencies.tsv
>
> On Wed, Oct 29, 2014 at 6:37 PM, Dimiter Naydenov
> <mailto:dimiter.nayde...@canon
.tsv
>
> Please use this command line when updating dependencies.tsv so
> that is keeps a standard format which will minimize conflicts in
> the file.
>
> -Nate
>
> -- Juju-dev mailing list Juju-dev@lists.ubuntu.com
> <mailto:Juju-dev@lists.ubuntu.c
in
>> "juju-team" and all was good.
>>
>> 1. Can we make it so that the review is published automatically?
>> 2. Can we pre-fill "juju-team" as the reviewer?
>
> Good catch. The two are actually related. The review is
> published, but that fails
id 1 supported version
> for Firewaller, because the new one can't get its job done with the
> old API.
>
> Thoughts?
>
> John =:->
>
>
- --
Dimiter Naydenov
juju-core team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJULogSAAoJENzxV2TbLz
lement
> Storage internally, for the time being, so there's no huge rush.
>
> Cheers, Andrew
>
>
- --
Dimiter Naydenov
juju-core team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJUJQqsAAoJENzxV2TbLzHwjk8H/3s8cRe8Db2StMckImw4VJ8+
baFNRjnW
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24.09.2014 10:46, Tim Penhey wrote:
> On 24/09/14 19:39, Dimiter Naydenov wrote:
>> I'm not opposed to replacing global keys with tags in state, but
>> using only simple _id fields in all collections is impractical in
>>
" gives us both a
way to get all machine NICs easily, but also guarantees there won't be
a chance to have a NIC with the same MAC on the same network and
machine. The same is much harder or impossible to do with asserts on
multiple fields and unique indexes, in a transaction.
I'm not opp
understand is how using tags as global keys will
solve the case with multiple environments in the same DB?
> One good part of this, is that for any element of the other
> collections, we can use the existing state.FindEntity(tag
> names.Tag) function.
>
> Is anyone opposed to thi
s the juju-core source.
2) If the sub-repo has changes that juju-core needs, create a "vX"
branch in the sub-repo with the changes (X = current+1, i.e. branch v4
from v3) and land this first, then change dependencies.tsv in
juju-core to use the new "gopkg.in/juju/charm.v4" and its
/github.com/juju/names/pulls. While I agree it's not all in one
place, I tend to work on the main repo mostly, and alternatively you
can check the Notifications page (https://github.com/notifications) to
see all activity.
Dimiter
>
> Rick
>
- --
Dimiter Naydenov
juju-core tea
t we
>> have moved to reviewboard without considering that it undermines
>> (as far as I can see) our primary reason for using GitHub.
>>
>> Jess
>>
>> -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify
>> settings or unsubscribe at:
>&
;s in trusty?
Thanks,
Dimiter
On 18.09.2014 13:45, Nate Finch wrote:
> IS specifically needs 1.18, and I believe that's what's in trusty.
>
> On Thu, Sep 18, 2014 at 6:43 AM, Dimiter Naydenov
> <mailto:dimiter.nayde...@canonical.com>> wrote:
>
> Yes, the is
n we added support for that, another thing we added was sort of
> a "charm store light" so that the GUI could interrogate for
> information about local charms (icon, etc). That code isn't doing
> the escaping it should have done, and Dimiter is working on it.
>
> Tha
it does.
I hope all that made sense and appreciate comments.
Cheers,
- --
Dimiter Naydenov
juju-core team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJUGVFEAAoJENzxV2TbLzHwQlwH/icQi0fcUtcVQseadE1hpvfW
L/WPM7NPpYw5Wgr74joMi4R6ExUki5kQiUGVO6Eoqa5cfZEpW6jXAloOzaN8+bdG
YCTU
and I'm up to date with master (for example I've done a
>> merge some time ago, probably before fixing a bunch of tests).
>>
>> Then it's just:
>>
>> $ git reset upstream/master $ git commit -am 'my commit message'
>>
>> whi
ite" - I only do that
in my own branches, which is not a problem (even after the initial
push, I still rebase, despite the branch going "public"). I guess this
won't work well if you have to collaborate with other people on the
same branch, but this is by far less common scenario
, Dimiter Naydenov wrote:
> Hi Eric,
>
> On 15.09.2014 21:18, Eric Snow wrote:
>> On Mon, Sep 15, 2014 at 11:05 AM, Katherine Cox-Buday
>> wrote:
>>> Let me preface this by saying I like the Reviewboard style of
>>> reviewing changes.
>>>
>>
quot; after the finaly "git sync" to create
a PR - the only thing missing is the RB steps.
> There is the possibility of pushing info from ReviewBoard back to
> github (e.g. "ship-it" -> "LGTM" comment), but I don't think it
> buys us enough to
e day after the
> mentees (or overlapping). Also tried to spread out the different
> timezones. It will never be perfect, but hopefully this is better
> now.
>
> Cheers, Tim
>
Great job Tim! No more poking into spreadsheets :)
- --
Dimiter Naydenov
juju-core team
-BEGIN
on a per-file file basis. BTW, it's common to fold
> "2012, 2013, 2014" to just "2012-2014".
>
> But I don't particularly care for upload purposes.
>
>
> Depending on the country, copyright notices require the first year
> of publication. I'm
that copyright expires.
>>
>> In practice, IMHO this is never going to matter since nobody is
>> going to care about the copyright on a piece of software that is
>> that old anyway. But I suppose laws could change, so the right
>> thing to do would be to add a new year w
9
lands, but for new code please follow the same pattern).
Cheers!
- --
Dimiter Naydenov
juju-core team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJUBZUhAAoJENzxV2TbLzHwewkH/AhtPOv1h3w+9LkyQdmH7Pbl
28cucj422TOXIek65+tB4fGmeCglQTPJkaLcsImWxKhYU7oAP9iT52lKjHiV377t
l7sSVprK
else finds it useful, and I'd appreciate feedback for it.
Cheers,
- --
Dimiter Naydenov
juju-core team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJT7NVmAAoJENzxV2TbLzHwlsEH/1GuYET5r/NvDQX7o9S3naEO
rPlmAM3+jeU3k3Pte50Gn6xpIY0whIjiDnrGE+UJaHaqFTQ
posing is implemented this will no
> longer happen. Does this seem like a problem to anyone? For
> instance, do we rely on the upgrade steps for the current version
> being run after bootstrap?
>
> The ticket for this work is
> at:https://bugs.launchpad.net/bugs/1350111
.
- --
Dimiter Naydenov
juju-core team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJT4dTFAAoJENzxV2TbLzHwJ6UH/08f/YeQ1GAv7a2iPrtd1ooE
9uQ0kK1wAs392woB8Q7SA5LE5x1lwWrg2F8EHdbMzGW+l/DuEGiey/Z8cR+jU52z
>
> -- Juju-dev mailing list Juju-dev@lists.ubuntu.com
> <mailto:Juju-dev@lists.ubuntu.com> Modify settings or unsubscribe
> at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
>
>
- --
Dimiter Naydenov
juju-core team
-BEGIN PGP SIGNATURE-
Version: Gnu
t;
> This test was added in pr 224.
>
> <https://github.com/juju/juju/pull/224>
>
>
> Can we have another look at these tests and fix them up to be
> properly robust? I don't want to back out changes that have been in
> trunk for a while, but we
uld add something there, like "Done" just to let the
>>> author know we are done with the review and not just reading a
>>> big confusing chunk of code. What do you people think?
>>>
>>>
>>>
>>
>> -- Juju-dev mailing list Juju-dev@l
ption). Once it's good to land,
edit that tag out and proceed, or if it's rejected, just delete the PR.
On 5.06.2014 12:03, Andrew Wilkins wrote:
> On Thu, Jun 5, 2014 at 4:43 PM, Dimiter Naydenov
> <mailto:dimiter.nayde...@canonical.com>> wrote:
>
> I spent som
> the general spam. Sadly, it doesn't allow the pull request to then
> be re-targetted to the Juju repo when ready to be reviewed for
> real. Or does it?
>
> Does anyone have any better ideas how to do this?
>
- --
Dimiter Naydenov
juju-core team
-BEGIN PGP SI
setting juju service config now.
>>>>
>>>> First source the credentials of the juju-tools-project user:
>>>>
>>>> $ source .gobotcreds
>>>
>>> You seem to have missed a key information step here.
>>>
>>> Where
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fwd to juju-dev. Having --level is a good suggestion, I like it.
- Original Message
Subject: Re: Debug-Log CLI / API Changes
Date: Wed, 19 Feb 2014 15:41:42 +0700
From: Stuart Bishop
To: Dimiter Naydenov
On 18 February 2014 23
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18.02.2014 17:03, John Meinel wrote:
> Can we make the API /uuid/api ? That makes them all peer paths.
Sure we can, I like that better in fact!
Dimiter
>
> John =:->
>
> On Feb 18, 2014 7:43 PM, "Dimiter Naydenov&quo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
As you may know, we're about to add extra features to the debug-log
juju command, which will add filtering and the ability to specify
entities which to include/exclude from the output. There are API
changes needed, but this message is to infor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
This is an announcement / request for comments for upcoming juju-core
API changes to the way AllWatcher works and also what URIs/paths the
API server listens to.
Very soon we'll make a few changes to the way AllWatcher work in the
API, and al
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Martin,
On 20.12.2013 16:31, Martin Packman wrote:
> On 20/12/2013, Dimiter Naydenov
> wrote:
>>
>> Since Martin is on leave and his branch
>> lp:~gz/juju-core/status_api seems almost ready to land, I decided
>&g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Update:
juju status +API will land with this CL:
https://codereview.appspot.com/38420046
(after the bot gets to it, it's Approved)
Dimiter
On 20.12.2013 10:42, Dimiter Naydenov wrote:
> Hi guys,
>
> Having landed API versions o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi guys,
Having landed API versions of "deploy" and "upgrade-charm" CLI
commands yesterday, the only thing left for the CLI API everywhere is
"status" (apart from "api-endpoints", but that's a bit of a gray area).
Since Martin is on leave and his bra
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10.09.2013 13:01, John Arbash Meinel wrote:
> On 2013-09-10 12:39, Frank Mueller wrote:
>> Hi all,
>
>> as on-call reviewer today I've again seen the difference between
>
>> https://code.launchpad.net/juju-core/+activereviews
>
>> and
>
>> https
alized - the On-Call Reviewer of course shouldn't
feel obliged to "share the burden" and LGTM the MP if he isn't
comfortable with the proposed change.
On 19.08.2013 11:02, Dimiter Naydenov wrote:
> I see where this is aimed - speeding up the review process, which
> t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I see where this is aimed - speeding up the review process, which
tends to stall at times for the lack of an additional LGTM. I also
think that, given time it'll improve our knowledge and certainty about
the codebase as a team and individually. Both of
85 matches
Mail list logo
