if branch < 400 lines, and no one requests more reviews, we require 1 review and 1 qa.
if branch >= 400 lines, or coder or reviewer requests, we require 2 reviews and 1 qa.
When we have daily calls, ask coder *and reviewer(s)* if there should be opt-in discussion of the branch.
Updates from August, 2013 Toggle Comment Threads | Keyboard Shortcuts
Dev environments don’t match charm production
rick – bit on last release, 0.8 in prod, 0.10 in dev. How to avoid compiling,
but also keeping that sort of inline
jeff – dependency of dependency, contextify needs g++
jeff – production has a weird imagemagick issue, building sprites, solution was
to lock down node to 0.8. To resolve, update local dependencies, update node on
the charm, make sure it deploys properly.
rick – doesn’t match test environment.
jeff – precompile and send with charm, gary disagrees – prebuilt assets
rick – chase down why it needed to change
ben and jeff – contextify needed? Need dev story for building non-release
versions. Don’t really have a good answer beyond updating dependencies.
rick – should be documented, wasn’t. Don’t mind stuff breaking so long as it
also breaks in dev. No releases on friday!
End: be aware that we have oddities that suck, but we should be upgrading
dependencies to work in both environments
jeff – styles don’t make sense, and kind of all over the place
rick – done by Huw to standardize fonts, because they were all over the place.
meaningful class names are probably not possible, and it is grepable
jeff – at least a naming convention?
rick – patches welcome, but probably no more fonts
jeff – whenever we need charm config details, they’re stored in one format and
never used in that format – always parse them into another format. Input on
changing formats in model so we don’t have to post-process
ben/matt – it’s what juju sends (notably pyjuju)
aaron – it’s stored different even in the api, mongo, elasticsearch
jc – patches welcome!
Existing problem all over the ecology
failure messages to assertions
jeff – should have failure messages due to number of assertions in a test, the
expecting true to be false or undefined. Hard to tell without rerunning
benji – because test runner doesn’t report line number
rick – +1
Curtis – +1, docstring in test gets printed out in python.
matt – way forward?
rick – reviewers look for it
jeff – if test failure would be ambiguous, add a message
IE10 mini retrospective
tickets: all known issues are fix committed, though a few low-hanging fruit
rick – takeaway: QA in IE10 – autocomplete good example
matt – most branches, qa in ie10 for next few weeks, major features and releases from here on out
scaling and target units
jeff – target units only makes sense if we have target units stored somewhere in
the bootstrap node. if user refreshes, number will be incorrect, though current
units will be fine – ditto other users, won’t know where we’re scaling to.
Core doesn’t support it, could be annotation on service, this is our target
ben – more than just an interface decision, gui can’t do things cli can’t.
jeff – scaling story is broken and buggy. Ongoing story, need design in on it
ben – allocate resource, advocate core change (target unit in core)
curtis – core has their own agenda that we have to take into account
ben – next step is to get the right people in a conversation
The GUI relies heavily on a sandbox mode and fake backend that mimics all of the functionality of a Juju environment in memory within the browser. This is how the GUI runs on jujucharms.com, in fact, and it is how we do much of our development. To ensure that both the environments for juju-core and the older pyjuju are fully represented, each of these is present in a sandbox form. A branch has just landed (and will be available in the next release) which completes all of the required operations in the juju-core sandbox mode. This means that we now have a full-featured testing and devel environment for the GUI and core which does not require spinning up any machines!
This is also the first step to implementing one of the newer features available in core that was not available in the older pyjuju: upgrading charms within a service.
CSS3 Animations from JS
I stumbled on this
which looks like a pretty lightweight way to extend what we do with animations. It doesn’t really use the same base JS we use elsewhere, but it looks thin enough that I don’t care.
Today, we made a GUI release of 0.8.2 and another jujucharms.com update. Unfortunately, I don’t have a lot of time to describe a release that has a lot of fixes that will make people happy. For a quick summary, though, here are five highlights in my mind.
- We stomped on a lot of different link issues in the charm browser (like these two).
- Charm upgrades deal with browser caches better now. This is coming to jujucharms.com soon, though we did make this release much smoother in that regard.
- We fixed the bug that made it impossible to destroy a service from the detail page.
- More legacy URLs are fixed.
- We made a lot of other small improvements, like showing when a charm is a subordinate.
Meanwhile some other changes were also made behind the scenes for upcoming features, which we will talk about soon.
We hope you enjoy it!
Matt: hygiene in tests (beforeEach/afterEach vs before/after) re: feature flags, but others too
When should we have test cleanliness, per test vs. per suite?
Gary says: if you are not thinking about it all, put test clean up after each test.
Rick says: if read-only change, then suite setup/teardown, if read-write, then test setup/teardown.
We all agree, and Aaron points that the underlying logic has to do with idempotency.