Updates from May, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • garyposter 4:50 pm on May 31, 2013 Permalink | Reply  

    Question: should we conditionally load some JS code, particularly for the code browsing experience?

  • garyposter 3:40 pm on May 31, 2013 Permalink | Reply

    Slack: how are we doing?

    Alright now, but messy. When we have stories our WIP limit is too high.

    Action items:

    • Gary will garden the kanban board to remove cards we don’t want any more.
    • Gary will tighten the WIP limit when we start our stories in earnest (and move the story lanes to the top of the board).

    Ben pointed out that our process means that we often can’t land things within a few hours, and that this discourages productive use of slack time. We acknowledged and while we would like to change our process to make short time spans more easily productive, we feel that prototyping, learning new technologies, and simply starting something that you know might be paused and turn into waste, are acceptable and useful uses of time.

  • garyposter 3:29 pm on May 31, 2013 Permalink | Reply

    Tests on Go.

    One part is CI. Gary will find someone willing to work on this with Marco to see if we can work with the ecosystems efforts.

    Another part is the sandbox. It currently only implements Python. We should have Go. We made that a high priority card to begin now.

    • garyposter 6:10 pm on May 31, 2013 Permalink | Reply

      Follow-up after the call: Francesco will investigate whether we can have the charm tests run the GUI integration tests cleanly. Nicola will investigate whether we can leverage charm testing infrastructure to tie in with tarmac for arbitrary runs, and whether we can leverage charm testing infrastructure to test charm branches before they land also.

      • Mark Ramm 8:23 pm on June 3, 2013 Permalink | Reply

        Did anything come out of this yet?

        • garyposter 10:58 pm on June 3, 2013 Permalink

          Yes. Francesco is on the first step of a three-part plan to make our charm able to run GUI tests. Nicola has been in touch with Marco and he is interested in helping this come to pass on his side. So, nothing concrete yet, but good signs. Next steps are for Francesco to continue down the road of coordinating the tests, and for Nicola and I to brainstorm about how we can work with Marco.

  • mitechie 1:59 pm on May 29, 2013 Permalink | Reply
    Tags: charmbrowser, staging   

    Yesterday we landed a change that moved the charm browser to be behind a feature flag instead of a hidden url. That means you no longer can access the browser with /bws urls. You’ll need to turn on the feature flag like so:


  • garyposter 4:02 pm on May 24, 2013 Permalink | Reply

    Matt: how much do we need a fakebackend and CI for jujucore.
    Ben: fakebackend is ok but we need new translation layer.
    Gary: My priorities:

    • CI against juju core most recent release
    • fakebackend is required too
    • CI against juju core trunk

    We are over time. Please comment on blog post!

  • garyposter 3:59 pm on May 24, 2013 Permalink | Reply

    Brad: Making a charm release now means pushing to a new group’s branch. This means that when we update our own charm branch with a problem, we see it before everyone else. tarmac still coming soon.

    New branch is lp:charms/juju-gui

    Us: we all cheered, very quietly, inside.

  • garyposter 3:55 pm on May 24, 2013 Permalink | Reply

    Reminder: don’t leave active card around on vacation. Options to resolve, from best to still good, are these:

    • actually land the card!
    • explicitly hand off the card to a volunteer
    • send an email to the list with enough information for someone to take your card further

    This includes cards that need to land (post review).

  • garyposter 3:51 pm on May 24, 2013 Permalink | Reply

    jeff: slimerjs is like phantomjs but for Firefox. Would it be nice to run these as part of our build step.

    ben: ok if it is packaged nicely. Otherwise concerned.
    jeff: yeah not in npm
    us: keep an eye on it, not mature enough for us yet.

  • garyposter 3:48 pm on May 24, 2013 Permalink | Reply

    Benji: dependencies shouldn’t be under app

    Can we move our assets not under app?

    ben: bower: package manager for browser dependencies
    gary: postpone until YUI supported?
    ben: yeah, maybe.

    gary: simplest thing we could possibly do would be to make a vendor top-level directory; move yui and d3 and anything else we didn’t write there; change devel server to look over there for the vendor files; and make sure that build-prod and build-debug continue to put the vendor files in the current location. Additional steps could be to investigate lib/views and do stuff.

    gary: I like reflecting what we serve.
    benji: app and vendor directory mimic what we serve as much as possible.
    us: ok, cool

    resolved as plan.

  • garyposter 3:29 pm on May 24, 2013 Permalink | Reply

    Nicola: our code is complicated. What can we do to follow our code better? Would inlineCallbacks help?

    charm.js and backends have events which make it harder. We are already using JS-style inlineCallbacks, effectively. We don’t think this would help.

    Matt has documented events which helps. Can we add an event system debug mode? Does something exist that helps?

    Ben: replace Y.log with a console.group
    Jeff: Turn on YUI debug files. Filter logs?
    Ben: console.trace gives you stack
    Gary: how do you do to figure out what callbacks are even registered?
    Ben: Chrome dev tool timeline rocks, but is hard to get started with.
    Us: Help us!

    Resolution: Ben will figure out an easy path to enlightenment for us.

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