Updates from August, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • garyposter 4:32 pm on August 30, 2013 Permalink | Reply

    New rule:
    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.

  • Madison Scott-Clary (Makyo) 5:17 pm on August 16, 2013 Permalink | Reply  

    Weekly notes Aug. 16 

    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

    Service config

    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

  • Madison Scott-Clary (Makyo) 7:34 pm on August 14, 2013 Permalink | Reply  

    Sandbox mode for juju-core 

    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.

  • bcsaller 6:06 am on August 8, 2013 Permalink | Reply  

    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.

  • garyposter 3:08 am on August 3, 2013 Permalink | Reply

    Juju GUI 0.8.2 and another jujucharms.com update 

    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!

  • garyposter 4:34 pm on August 1, 2013 Permalink | Reply

    Matt hygiene in tests beforeEach afterEach vs before… 

    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.

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc