Yellow Squad Weekly Topics: December 14

Summary:

• Makyo: the GUI can break the charm
• bcsaller: Write user stories as functional tests: improv plus Selenium
• bcsaller: card velocity improving
• gary_poster: run the tests before landing, or, we are not as good as an automatic tester
• gary_poster: teknico is "documentation daddy"
• bcsaller and Makyo: proliferation of ENV=1 make [target] rules
• goodspud: what do we do with the juju-gui charm in the gui?

[introduction] [project report] [topics]

Attendance: alejandra, bac, bcsaller, benji, frankban, gary_poster, goodspud, hazmat, Makyo.
Apologies: teknico.

Everything below is paraphrased, and errors are likely gary_poster's. Initial italicized IRC nicks identify speakers.

Makyo: The GUI can break the charm

Makyo: We were talking last week about reasons why our velocity might have slowed down recently, particularly once we started the new project goals. I think that one reason might be frequent breakages of our charm. It has slowed me down, and I have noticed others have had problems also. Even though we have tests of our GUI application and tests of our charm, the charm depends on the GUI's trunk. GUI trunk changes can break the charm, slowing us all down.

gary_poster: Makyo and I discussed this earlier. I thought this made a lot of sense as one cause of our reduced velocity. It also is a specific case of the hypothesis from our discussion last week that we were slowing down temporarily because we were starting a new goal, with growing pains at the start.

Makyo and I agreed that our plan to use QA'd GUI releases rather than trunk as the default charm source would really help this. This is tracked in bug 1088618. That should also significantly speed up our charm deployment and charm tests. It is one of our cards scheduled for this upcoming week.

all: Sounds good.

bcsaller: Write user stories as functional tests

bcsaller: As mentioned last week, we might want to convert our user stories from the design team to Selenium functional tests, connecting to our improv mock environment.

gary_poster: I would happy to make a slack task to explore this.

frankban: Selenium might be nice for charm tests also. That way we could verify that the charm actually produced a fully working environment, and not just that, for instance, the Makefile succeeded and we are serving an index.html.

goodspud: We on the design team could actually write the user tests as scripts and ask users to run them periodically as tests.

gary_poster: The scripts themselves would certainly be very useful for us to perform QA with ourselves, prior to releases.

alejandra: I would like to think and talk about this some more with goodspud before we discuss more.

ACTION: goodspud and alejandra will tell us how they might want to work with us on this.

bcsaller: Card velocity improving

bcsaller: I had a card that took more than a day to move through the coding lane. We discuss cards like these at the retrospective per our standard policies. My observation is simply that I am improving my approach to incrementalism, and increasing my appreciation of it.

gary_poster: run the tests before landing, or, we are not as good as an automatic tester

gary_poster: At least one branch landed on the GUI project without the tests passing. While this breaks our policies, at the end of the day, the core problem is that we should have automatic testing, as we have discussed before.

all: We all agree. lbox could do this in our hooks if we used Selenium or some other JS runner to verify the test output. The question is what priority to place this.

ACTION: gary_poster to create a slack card to make this happen. Selenium might be an easy, fast way to do this that works with our existing tests and lbox, and gives us what we want soon.

gary_poster: teknico is "Documentation Daddy"

teknico is very interested in improving our documentation. He's taken formal responsibility for guiding us to at least double our documentation in the next four months, and to get our documentation published at a stable, publicized URL. Beyond that, I would like us to recognize him as a documentation leader within our team. That would mean two additional things.

• If we are not able to come to a consensus about a documentation issue, we look to him for a decision.
• We invite him to review our documentation efforts on an ongoing basis. We welcome him to guide our documentation efforts individually, such as in code reviews; and collectively, such as in weekly retrospectives.

We can see how this goes and evaluate it in January.

Everyone seems to generally be OK with this.

ACTION: gary_poster will set up a time in January to check on how this is going.

bcsaller and Makyo: proliferation of ENV=1 make [target] rules

Makyo: In a review of a branch of mine, bcsaller raised a concern that our use of environmental variables in our Makefile was confusing and overdone. The Makefile has been a source of annoyance for me as well.

bcsaller: Beyond the environmental variables, my concern is that our Makefile is over 400 lines and generally confusing. Make is not a good programming environment. I'd prefer to see another language used.

hazmat: +1. I would like us to consider Grunt, since we already are using that for some of our build tasks.

benji: I think we have bigger fish to fry than to work on this now. I'd prefer to see tests of our build process.

hazmat: Agreed that we have other more important tasks in front of us. That said, we could write tests of our build functions if we used another language.

benji: I'm more interested in tests of the results of the build process--verifying that a successful build or a successful release produces what we expect. This could be valuable whatever our build tool was, and would also address a practical problem we have now.

hazmat: OK.

gary_poster: We have heard repeated concerns about the Makefile from many of the engineers, so this is something to improve. That said, I agree with benji that it is does not seem valuable enough to address this now.

Everyone seems to generally be OK with this.

goodspud: what do we do with the juju-gui charm in the gui?

goodspud: gary_poster sent out an email asking about what we should do in the the GUI about the GUI charm. Right now, if you start the GUI with the charm, you see the GUI charm in the GUI. You can also remove the charm, which will mean that the GUI will suddenly die. Unexposing it will also kill the GUI. I replied suggesting that we ought to make some warnings and move on. What do we think?

hazmat: When we talked about this before, I advocated hiding the GUI charm, and that's still my position.

gary_poster: Will people want to manipulate the GUI charm, like adding more units to it?

hazmat: Maybe, but I don't think it is likely in the short term, and giving people a hidden, potentially surprising switch to turn off the GUI is something really to avoid.

alejandra: I agree with hazmat.

goodspud: OK.

everyone else: OK, decision made.