Updates from June, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • garyposter 3:39 pm on June 21, 2013 Permalink | Reply  

    charm release process
    1) we should make one!
    2) part of that process is not only to run the charm tests, but also the GUI tests.

    Nicola will add a charm release process document to the charm.

  • garyposter 3:36 pm on June 21, 2013 Permalink | Reply

    Coffeescript and other new technologies. Gary proposes that we postpone discussion until we catch our breath around 13.10 again. Everybody seems ok with that.

  • garyposter 3:34 pm on June 21, 2013 Permalink | Reply

    Root cause analysis

    We had a release with a big bug. Neither our tests or our qa caught it.

    So far, to respond to the problem, we have two approaches in progress. First, Diogo is working on scheduled exploratory testing. How can we do that well? Second, we are discussing whether a qa checklist of things to do before release will help.


    • Gary will talk to Matt to incorporate Exploratory testing, and Diogo’s help possible, into our release process. This will include identifying new features for Diogo to attack.
    • We will have a script-based testing also as part of the release process. It will explicitly focus on first-time user experience.
  • mitechie 12:52 pm on June 21, 2013 Permalink | Reply
    Tags: css sass chrome workflow   

    A little bit of a follow up on my previous post on teaching chrome about files on disk is this net|tuts post on editing sass files in the chrome dev tools with a combination of source maps and local file storage knowledge.


  • Benji York 1:36 pm on June 18, 2013 Permalink | Reply  

    Juju GUI version 0.6.0 Released 

    We are happy to announce that the 0.6.0 release of the Juju GUI is available.

    Changes include:

    • New charm browser for finding available charms.
    • Visual styling changes.
    • The beginnings of a Go backend sandbox.
    • Bug fixes and improved CI reliability.
    • Automatic view portal zoom and centering.
    • Support for Google Analytics.
    • Linting of yuidoc comments.
    • Linting of copyright headers.
    • Linting of project documentation files.
    • Utility for recording and playback of websocket traffic for debugging.
    • Caching of search results.
    • Improved development HTTP server behavior.
    • Improved project documentation.
  • bradcrittenden 2:28 pm on June 17, 2013 Permalink | Reply  

    Juju-core hangout notes 

    I sat in on my first juju-core hangout. Not much of interest was said. Procedurally,

    • Ensure you have acccess to their kanban board beforehand. If you don’t have permission ask MRamm.
    • Be prepared to give a quick juju-gui status update to them.
  • garyposter 4:05 pm on June 14, 2013 Permalink | Reply

    [ACTION] Team, please review https://bugs.launchpad.net/juju-core/+bug/1089301 to see if we could use it to effectively work around the absence of debug hooks. We will talk about it next week.

    Also, go ahead and please mark yourself as affected by the debug hooks bug. 🙂

  • garyposter 3:58 pm on June 14, 2013 Permalink | Reply

    hanging out on Juju Core calls: valuable?
    Benji: we reminded them we exist, but that was it. negligible value. evaluate another week or stop.
    Matt: got value out of it. Was working on Juju core. Evaluate another week.
    Nicola: negligible value. Evaluate another week.

  • garyposter 3:55 pm on June 14, 2013 Permalink | Reply

    Jeff: newer jshint would be nice, especially as we start using newer JS features
    Gary: isolated from other dependencies we need to upgrade?
    Jeff: maybe. 🙂
    Gary: may not have time at this moment, but slack or as needed is fine.
    [ACTION] Gary will make low priority card

  • garyposter 3:50 pm on June 14, 2013 Permalink | Reply

    Jeff: code coverage analysis would be great. Istanbul is one JS tool for this. It might not work with our Mocha variant usage, but we can make it happen. Let’s add it.

    Benji: +1, but IME 100% test coverage is necessary but not sufficient. Analyzing individual modules with their associated tests gives much better results than analyzing all modules with all tests at once.

    Jeff: keeping behavior app extensions or separate objects can keep tests more tightly focused.

    Gary: Istanbul is the “best test coverage tool”?
    Jeff: It has a lot of momentum and I know how to use it. We might want to investigate other options before committing.

    Gary: test coverage can’t decrease? Like undocumented file?
    (undocumented file approach has not worked as well as I would like)
    (Jeff: we could improve)
    (Benji: yes)
    (Nicola: plus when undocumented file is regenerated order is different)
    (Benji: how easy to fix it so that callbacks are not listed as needing documentation?)
    (Benji: not clear)
    Maybe we could do something similar to undocumented file to get code coverage increasing in the future. However, hopefully our slack time/maintenace time is going to be decreasing for the next couple of months at least, which will mean that we have minimal time for this.

    [ACTION] Gary will make a low priority card for investigating code coverage tools and then incorporating one.

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