[12:21] NOTICE: about to make a release [12:55] yow, it's a little cooler this morning than I expected, -7C [13:34] will someone else check that the release candidate tarball on staging is fit for final release? thanks https://staging.launchpad.net/juju-gui/stable/0.2.0/+download/juju-gui-0.2.0.tgz [13:35] teknico: I'll be glad to look, although I'm not entirely sure what all should be checked [13:36] benji, thanks, there are some suggestions in the release checklist, in docs/process.rst [13:37] cool, I'll look at those [13:37] frankban, how do I "juju deploy" from staging? [13:44] teknico: the release looks good. The tests pass and I started the app and poked around in it for a while and everything worked as expected and no JS errors were generated [13:45] benji, great, thanks [13:45] my pleasure [13:47] teknico: you can't. You may want to make and upload a trunk release and then test it before uploading the stable one, e.g.: "juju-gui-source: trunk" in the config file. you can also run the charm tests against trunk setting the env var JUJU_GUI_SOURCE: JUJU_GUI_SOURCE=trunk jutsu test... [13:59] frankban: speaking of the charm, I haven't been able to use the juju-gui-source setting to get the charm to run against a different release; is it supposed to work and how am I supposed to use it? (I have been doing a "juju set" just after deploying the service.) [13:59] benji: it should work [14:00] ok, I'll try again and see if I can track down what is going wrong; I assume the "juju set" bit is the right way to do it, correct? [14:01] benji: something like "juju set juju-gui juju-gui-source=0.1.4 [14:02] frankban: oh, I thought you could give it a branch URL [14:02] benji: otherwise you can pass a customized config.yaml to deploy --config [14:02] benji: yes, that too, e.g. juju-gui-source=lp:juju-gui [14:03] cool; I'll try harder then ;) [14:04] benji: it is considered a branch if it starts with "lp:" or "http://" [14:04] oh, so no "bzr:"? That is probably where I was going wrong. [14:06] benji: precisely, we should add the "bzr:" scheme too, it's quite easy, feel free to create a card if you want to [14:06] frankban: will do [14:06] benji: cool thanks [14:08] benji, while you're at it, maybe add to the card the possibility to deploy from staging :-) [14:08] teknico: sure :) [14:09] frankban: https://bugs.launchpad.net/juju-gui/+bug/1112529 [14:09] <_mup_> Bug #1112529: Support "bzr:" scheme in juju-gui-source charm setting. < https://launchpad.net/bugs/1112529 > [14:09] teknico: https://bugs.launchpad.net/juju-gui/+bug/1112530 [14:09] <_mup_> Bug #1112530: Support deploying the GUI charm from LP staging < https://launchpad.net/bugs/1112530 > [14:09] thank you! [14:11] benji, thanks [14:11] np [14:16] guihelp: I wonder how, now that the charm is in the store, we are supposed to re-propose new changes [14:21] teknico: done? [14:21] frankban, what? [14:21] teknico: the release [14:21] frankban, nope, still upoading [14:21] or something :-) [14:23] frankban, merge proposal .. with approval by charmers [14:24] frankban, but I think there's no need to wait landing branches now [14:24] frankban, so ideally if there's a round of dev on it, we'd do it with our normal process against the team branch, and then propose to the official charmers version [14:25] hazmat: so, we might want to collect some changes before re-proposing [14:25] frankban, yes [14:25] hazmat: cool, thanks [14:25] frankban, technically the distinction isn't in the store but the owner in the store. [14:25] np [14:26] frankban, finished, https://launchpad.net/juju-gui/+milestone/0.2.0 [14:27] teknico: great! [14:27] frankban, its about 2-5 days for a charmers review.. this their queue http://jujucharms.com/review-queue [14:36] hazmat: ack. so, I'd suggest, e.g. when testing the GUI (deployments, new releases, etc.), to always use the latest version of our charm, i.e. most of the times, the one owned by juju-gui. what do you think? [14:48] frankban, sounds sensible, but socially we want to continue distill/promote to charmers (aka the official charm) [14:48] hazmat: of course. agreed [15:02] teknico: the release tarball seems broken :-( . http://pastebin.ubuntu.com/1597149/ [15:03] what?!? [15:04] teknico: I am downloading the tarball, I will try to uncompress it manually. [15:05] frankban, me too, the local copy is correct [15:07] the size is wrong, and the content is junk :-( [15:07] teknico: I confirm the uploaded tarball is broken. please remove the release [15:08] frankban, done, I'll upload again [15:11] guihelp: the release tarball on staging is correct. Is there a way to upload that copy to production, rather than the one I have locally? [15:15] teknico: I don't know and I guess no. however, why do you want to do that? I suggest to try the release process again, it could be nice to find what's wrong. Is there a final tarball (downloaded from launchpad) qa step? if not, we should add it. [15:15] teknico, define production? [15:16] hazmat, I meant stable [15:17] frankban, I'd like to do that because it would be easier and faster. The release process has went well up to generating the tarball: as I said, the local one is correct. I am uploading it again. [15:18] teknico, i don't know, effectively your asking can we can copy tarballs in launchpad to replace a broken one? [15:18] frankban, you can find the release checklist in docs/process.rst. There are a number of qa steps, I'll add one more. [15:18] teknico, that seems best.. if the tarball is entirely broken.. replacing/updating seems okay.. [15:19] hazmat, I deleted the broken one already [15:19] hazmat, I'm asking if we can do a lp-to-lp copy in place of a standard upload, as a matter of convenience [15:19] teknico: thanks, I believe that checking that everything is ok with the tarball at the end of the process is without doubt a good idea ;-) [15:20] frankban, I guess we hadn't yet had problems with the final uploading step [15:21] I'm still mistified how this could happen [15:21] teknico, not that i know [15:21] how do you end up with 34MB of garbage after having uploaded a 25MB tarball? [15:22] teknico: try to restart your router ;-) [15:22] frankban, I'll see if they can restart the internet [15:25] https://www.youtube.com/watch?v=iDbyYGrswtg [15:25] broken again :-( [15:25] this is even weirder though: [15:26] the gpg signature on lp is correct, while the file is not [15:27] the Elders of the Internet want us to have a standup in 3 minutes [15:27] I guess the upload_release.py script uploads the .asc signature file too [15:30] Hey all. Are we having our daily stand up today? [15:30] * frankban connecting to the Internet for the daily call [15:30] deleted again :-/ [15:34] is ther a standup? [15:34] looks like [15:44] teknico: at least len(juju) < len(ensemble) [15:44] bac, that's true :-) [15:52] :-) [16:04] bcsaller, we're really short on pyjuju reviewers.. if you have a moment would you mind having a look at https://codereview.appspot.com/7241062/ [16:04] hazmat: yeah, just proposed my branch so I can look at that one now [16:04] bcsaller, thanks, its thankfully pretty small [16:05] a one liner and a drive by [16:07] teknico: a small branch you might review: https://codereview.appspot.com/7231077 [16:09] benji, looking [16:10] benji, there's a conflict in the lp diff, and Rietveld says "error: old chunk mismatch" on docs/process.rst [16:10] darn; let me look [16:14] teknico: fixed: https://codereview.appspot.com/7231077 [16:15] benji, looking [16:15] benji, I uploaded the release tarball to U1 (and downloaded it to check, successfully) [16:15] benji, I shared a folder with you, you should have an email [16:15] benji, in the folder you'll find the tarball and the .asc signature file [16:16] teknico: cool. I suppose that I should pick up the release instructions just after the bit about making sure the release works, right? [16:16] benji, yes, you should put both of them in a releases/ directory in a juju-gui branch [16:16] k [16:17] benji, well, the release checklist says to run "FINAL=1 PROD=1 make dist" [16:17] benji, that also tries to build the tarball [16:17] benji, you only need to run the last step: "python2 upload_release.py juju-gui stable 0.2.0 releases/juju-gui-0.2.0.tgz" [16:18] sounds good [16:18] benji, however, I don't know where the upload_release.py script comes from :-) [16:18] it appears in the branch dir during the release process [16:18] like, it's magic ;-) [16:18] I can work that magic. [16:19] that's good :-) [16:31] benji, do you have time for a quick hangout? [16:31] teknico: sure; is juju-ui free? [16:31] let's see [16:31] it is [16:50] James is home sick, I'm going to duck out to a coffeeshop. Hopefully less awful coughing there. [16:52] teknico: https://codereview.appspot.com/7231077 [16:59] benji, looking [16:59] k [17:09] so, you think you love JavaScript? http://dmitry.baranovskiy.com/post/91403200 [17:13] guihelp: I cannot find the standard review markers we decided upon ("Land as is", "Land with changes" and so on), where are they? [17:14] teknico, I don't know if we wrote those down anywhere. It's those two and "request re-review", as far as I know. Any suggestions on where we should put them? Docs, maybe? [17:14] process.rst would do the trick [17:15] that's where they are! [17:15] silly me, I was reviewing exactly that file :-D [17:15] Oh! Well, there you go :) [17:15] it must be friday afternoon ;-) [17:17] benji, I'm sorry, one more iteration needed :-) [17:17] heh, no worries [17:17] comments in the review? [17:18] benji, yep [17:18] cool [17:27] Makyo: can I ask what you found to be at the core of the dragging issue? [17:27] teknico: once more, with feeling! https://codereview.appspot.com/7231077 [17:28] benji, allegretto con brio! [17:29] bcsaller, When things were updated, the datum associated with each service didn't equal the datum passed in as 'd' to drag. When setting the translateStr in selection.attr('transform', function(d) { return d.translateStr(); }), we were also overloading the 'd' variable. Changing it to function(datum) and still using 'd' fixed that. [17:29] :) [17:29] ahh [17:30] bcsaller, Additionally, the service in the relations was being matched on modelId, but the relations objects were stale, so relation lines weren't updating properly either. [17:31] ...relations which used to be 'relPairs', to clarify. [17:32] benji, done [17:32] I guess we need to come up with some joke like: "What do you call two perfectionists one-upping each other? ..." [17:33] missing the closing part though :-) [17:36] teknico: I have a good punchline but if I tell you, you will come up with a better one. [17:37] benji, true, but someone's got to give in sooner or later :-) [17:37] benji, btw, any luck with the release upload? [17:38] teknico: I got the file, but other than that I have been distracted by the QA bits. I'm looking at it now. [17:39] benji, out of curiosity, what upload bandwidth do you have available? [17:39] teknico: 5 megabit [17:39] upload?!? oh wow. oh wow. [17:40] my link is hilariously asymmetrical: 100 down, 5 up [17:41] well, around here it can be 20 (nominal) down, .3 up, so... [17:41] more than .5 up is almost unheard of [17:41] that is 0.3 and 0.5 resp., to be clear [17:42] yeah, that's common here too; one of the big reasons to buy this particular house was that a good connection was available [17:42] https://files.one.ubuntu.com/sEhlVl2GRu28wl3nHw2rhw [17:42] bcsaller: can you see that link? [17:43] bac: after SSO it gives me an error [17:43] doh [17:44] * Makyo discovers lack of charger in laptop back. Back home [17:45] Makyo: when you walk into the house start yelling "Unclean. Unclean!" at the top of your lungs [17:47] bcsaller: was trying to show you the screenshot for bug 1112717 [17:47] * bac needs to figure out ubuntu one share settings [17:48] bac: its on the bug itself, right? [17:48] I can see it there [17:48] bcsaller: yep [17:48] just another amusing/hair pulling bug [17:49] thats great :-/ [17:49] bcsaller: if you can think of things you think may be broken let me know and i'll try them [17:49] so far it is fish in a barrel [17:50] bac: I find that surprising as is, at this point I'd assume it mostly doesn't work. Anything with a transform attr on it is suspect it sounds like [17:51] bcsaller: do you think the exercise is pointless atm? [17:51] i.e., is there a class of problem that may be solved in one way so there's no need to identify them all? [17:51] bac: no, generating a list of things that don't work is fine, but I don't think you need to find them all, just calsses of errors [17:51] classes [17:52] sounds like the same thinking [17:52] calluses of errors