20:00:23 <r1chardj0n3s> #startmeeting horizon
20:00:24 <openstack> Meeting started Wed Dec  7 20:00:23 2016 UTC and is due to finish in 60 minutes.  The chair is r1chardj0n3s. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:28 <openstack> The meeting name has been set to 'horizon'
20:00:30 <ediardo> o/
20:00:37 <r1chardj0n3s> o/
20:00:46 <lcastell> o/
20:01:40 <rhagarty_> 0/
20:01:50 <ducttape_> o/
20:01:57 <r1chardj0n3s> so, Ocata-2 is next week (ohmygosh)
20:02:05 <r1chardj0n3s> #topic Priority patches for review
20:02:12 <r1chardj0n3s> #link https://review.openstack.org/#/q/starredby:r1chardj0n3s%20AND%20status:open now has some angularjs panels listed, will add more
20:02:14 <david-lyle> o/
20:02:57 <r1chardj0n3s> I've started adding the priority angularjs panels to that list, and will add some more. Trying to limit it to just the ones that are most likely to be completed in this release.
20:03:18 <r1chardj0n3s> ie. the ones that have table, create, delete and edit actions at least partially implemented
20:03:23 <ediardo> Check this https://review.openstack.org/#/c/366957/
20:03:27 <clu_> o/
20:03:55 <robcresswell> r1chardj0n3s: Nothing on Users?
20:04:19 <ducttape_> ediardo - would like to follow up on that link later
20:04:20 <r1chardj0n3s> robcresswell: which user patches?
20:04:47 <robcresswell> https://review.openstack.org/#/c/336394/
20:05:09 <robcresswell> Just that I would imagine there is more demand for Users to be functional than Roles, no?
20:05:44 <rdopiera> o/
20:05:52 <ducttape_> I'd agree that users and projects are more heavily used than roles robcresswell
20:05:56 <r1chardj0n3s> robcresswell: yep, absolutely. I just somehow didn't see that patch when I skimmed ... will add to the priorities etherpad :/
20:06:06 <robcresswell> Cool
20:06:28 <r1chardj0n3s> starred!
20:06:29 <robcresswell> There's also a whole instances implementation sat in searchlight ui if someone wants to look at porting that
20:06:46 <robcresswell> Would also be a good panel to improve *hint hint*
20:06:49 <robcresswell> :)
20:06:55 <r1chardj0n3s> agreed
20:07:18 <r1chardj0n3s> any other users patches i've omitted from the priority list?
20:07:38 <robcresswell> Not sure atm, I threw a tantrum at everyone using identity-tables blueprint and -1'd them all
20:07:54 <robcresswell> It had like 100 patches so I've no idea what was relevant
20:08:10 <r1chardj0n3s> https://review.openstack.org/#/c/342170/ perhaps
20:08:50 <ducttape_> I have a cinder patch that is old as dirt, around quotas
20:08:57 <r1chardj0n3s> and https://review.openstack.org/#/c/361529/
20:09:02 <robcresswell> yeah, looks like there are a few on there. Either way, it would be great to focus on getting Users in a good position especially while we have the Keystone meeting each week
20:09:05 <ducttape_> but the quota rework is probably the thing to focus on
20:09:23 <robcresswell> ducttape_: Yeah, has quota reworks gone stale? Or is that still a thing?
20:09:35 <r1chardj0n3s> we still need a solution for search-first to replace the user listings in other parts of our UI
20:09:59 <r1chardj0n3s> I think I was throwing ediardo or lcastell at that problem tho
20:10:08 <robcresswell> \o/
20:10:16 <ediardo> \o/
20:10:17 <ducttape_> quota rework is a thing, just can't get enough time to work on it.   welcome any all help
20:10:24 <clu_> (https://blueprints.launchpad.net/horizon/+spec/ng-users exists, so we can link to that instead)
20:10:25 <r1chardj0n3s> ducttape_: got links?
20:10:41 <ducttape_> https://review.openstack.org/#/c/309204/   is the old one
20:10:54 <ducttape_> it is ready for review, could be merged
20:11:07 <ducttape_> well, except jenkins, but it is close to done / ready
20:11:14 <robcresswell> ducttape_: I'm pretty swamped right now, freed myself up and immediately got a ton of work. Plus internally I've got Kubernetes work. My career plan has just become "follow david-lyle"
20:11:19 <robcresswell> Can review though
20:11:24 <ducttape_> k
20:11:43 <robcresswell> clu_: Thanks for that!
20:11:50 <ducttape_> quota rework needs to be rebased and redo all the tests still https://review.openstack.org/#/c/356605/
20:12:09 <r1chardj0n3s> if anyone feels like a patch should be priority please let me know even outside of this meeting :-)
20:12:29 <r1chardj0n3s> ducttape_: ack
20:12:40 <r1chardj0n3s> #topic Integration tests are broken, getting no attention at all, and should be removed altogether
20:12:56 <r1chardj0n3s> ... discuss
20:13:11 <ducttape_> I think the out right broken things have been corrected pretty quickly (in the last few weeks), we have master - 5 days in our lab right now
20:13:37 <rdopiera> even the simple tests we have are still useful
20:13:49 <rdopiera> I found a bug with one yesterday
20:14:02 <rdopiera> the problem is, nobody knows how they work or how to run them locally
20:14:25 <r1chardj0n3s> we don't have a plan for stability in the gate
20:14:29 <r1chardj0n3s> we don't have anyone in the community who has fixing them as a priority
20:14:30 <robcresswell> rdopiera: They've been failing and non-voting for months
20:14:39 <rdopiera> robcresswell: one is voting
20:14:50 <r1chardj0n3s> rdopiera: do you mean tempest?
20:14:52 <lcastell> if they can pass along the knowledge to us, we have some hands available
20:14:57 <rdopiera> r1chardj0n3s: yes
20:15:09 <r1chardj0n3s> rdopiera: that's not really a test ;-) it just checks the login screen appears
20:15:27 <rdopiera> r1chardj0n3s: well, it's a test if it finds bugs, and it found one yesterday
20:15:28 <david-lyle> r1chardj0n3s: it does a bit more
20:15:37 <r1chardj0n3s> it's still worth having, sure
20:15:40 <david-lyle> it tests that login work
20:15:50 <rdopiera> david-lyle: by the way, I will ask you for some help with that later
20:16:00 <rdopiera> david-lyle: if you don't mind
20:16:13 <robcresswell> Yeah, it also runs through static collecting and compressing as part of the setup, so settings issues will be caught too.
20:16:18 <david-lyle> whatever help I can provide
20:16:23 <r1chardj0n3s> lcastell: perhaps, if we can get you and timur talking
20:16:35 <rdopiera> r1chardj0n3s: I'd like to try and get that to work
20:16:38 <lcastell> yep
20:16:47 <rdopiera> r1chardj0n3s: the non-voting tests, I mean
20:16:54 <rdopiera> r1chardj0n3s: if I fail, we can revisit the issue
20:16:56 <r1chardj0n3s> the basic issue though isn't with any specific tests, it's with the fragility of the whole setup
20:17:09 <ediardo> Yes, let me know , I can help too
20:17:10 <r1chardj0n3s> we are constantly being broken by some new release of firefox or selenium
20:17:25 <david-lyle> or some timeout
20:17:29 <r1chardj0n3s> or some timeout
20:17:32 <rdopiera> well, that's modern software development :)
20:17:43 <rdopiera> or leftpad.js
20:18:08 <r1chardj0n3s> node.js programming language issues don't tend to be the cause of breaking our selenium tests
20:18:08 <david-lyle> but the noise to signal ratio is much too high for anyone to actually think their new code may have broken something
20:18:11 <robcresswell> No, this was next level stuff
20:18:33 <robcresswell> We had like a 25% pass rate on functioning code before we disabled them
20:18:38 <robcresswell> and thats when they were "working"
20:18:59 <david-lyle> I'd prefer we focused on getting unit tests passing on xenial first
20:19:06 <r1chardj0n3s> ediardo / lcastell I will put you in touch with timur to discuss a way forward
20:19:16 <lcastell> sounds good
20:19:17 <robcresswell> It's pretty cryptic syntax too, which doesnt help a great deal.
20:19:28 <robcresswell> david-lyle: UTs fail on Xenial?
20:19:31 <ediardo> ok, ty
20:19:34 <r1chardj0n3s> david-lyle: our tests don't pass on xenial??
20:19:34 <lcastell> we already talk about it las mid cycle so...
20:19:47 <tqtran> 0/ sorry im late, just caught up with the script
20:20:17 <david-lyle> r1chardj0n3s: nope
20:20:35 <r1chardj0n3s> david-lyle: I'm confused, becuase I see tests passing
20:20:42 <david-lyle> two failing non-voting runs at the bottom of every patch
20:21:18 <r1chardj0n3s> david-lyle: but that's the selenium tests we've been talking about
20:21:27 <robcresswell> thats the integration tests
20:21:40 <david-lyle> selenium and integration tests are two very different things
20:21:51 <david-lyle> the selenium tests pass generally
20:22:16 <david-lyle> not in xenial because the xvfb lib is not installed by default
20:22:31 <david-lyle> any more
20:22:51 <r1chardj0n3s> david-lyle: that's part of the whole mess of issues around ubuntu breaking selenium with firefox/selenium (And now xvfb) releases that break us, yes
20:23:15 <david-lyle> oh nevermind
20:23:25 <robcresswell> Yeah, the xenial issue might be new, but those integration test runs were set to non-voting before that point
20:23:32 <david-lyle> the tests are different but I didn't see the xenial was integration
20:23:34 <r1chardj0n3s> sure, the selenium and integration suites are two separate things, but they both *use* selenium and that's the fragility we have
20:23:45 <robcresswell> right
20:24:12 <r1chardj0n3s> ok, I'm gonna see if we can get ediardo and lcastell to fix it, working with timur to extract all his knowledge :-)
20:24:12 <rdopiera> the alternative is to go blind, which is even more fragility
20:24:15 <r1chardj0n3s> moving on?
20:24:25 <r1chardj0n3s> (to something much simpler)
20:24:28 <r1chardj0n3s> #topic Microversion support
20:24:29 <lcastell> :)
20:24:31 <david-lyle> personally I think that test suite is a waste of time
20:24:43 <r1chardj0n3s> #link https://etherpad.openstack.org/p/horizon-microversion-support is where we’ve been discussing the approach
20:24:57 <david-lyle> once it's patched it will break and it's limited in time duration
20:25:06 <david-lyle> it's half sleep calls
20:25:08 <robcresswell> rdopiera: Well, they are non-voting, so we are already blind
20:25:12 <robcresswell> so nothing would change
20:25:15 <david-lyle> ok done
20:25:32 <rdopiera> robcresswell: I agree that setting anything to non-voting doesn't make any sense -- just disable it
20:25:51 <robcresswell> r1chardj0n3s: On microversions, I realised we've gone full circle with the approach now
20:25:58 <r1chardj0n3s> robcresswell: \o/
20:26:00 <tqtran> so... do we have a replacement in mind? or will horizon not be doing tests at all?
20:26:07 <rdopiera> 3rd system syndrome?
20:26:13 <david-lyle> tqtran: it's only integration tests
20:26:23 <r1chardj0n3s> ok, putting microversions discussion on hold
20:26:30 <robcresswell> tqtran: Well, we need someone to work on it, and noone is
20:26:36 <r1chardj0n3s> no, no-one has proposed an alternative to selenium tests
20:26:36 <robcresswell> So... thats kinda all there is to it
20:26:38 <tqtran> ok thats fair enough, i cant get those to run locally, so testing them was a PITA to begin with
20:26:59 <r1chardj0n3s> we have to have that level of testing to have confidence, but only if we can make it work
20:27:02 <david-lyle> selenium works, integration tests use of selenium does not
20:27:11 <robcresswell> Right
20:27:24 <robcresswell> perhaps we should consider more tempest scenarios?
20:28:01 <david-lyle> I'd prefer that to integration test suite
20:28:10 <rdopiera> sounds reasonable
20:28:57 <david-lyle> without massive rework I just don't see the integration tests being useful
20:29:12 <david-lyle> they've been flaking for 4+ releases
20:29:17 <r1chardj0n3s> david-lyle: what is it in our integration / selenium test suite use of selenium that differs from the tempest use of it?
20:29:21 <david-lyle> that's not going to change with a few days of love
20:29:46 <david-lyle> r1chardj0n3s: good question
20:29:49 <david-lyle> :)
20:30:12 <david-lyle> The selenium tests are launched the same as any unit test but happen to use selenium
20:30:13 <r1chardj0n3s> david-lyle: 'cos if we don't know that then it's pointless moving everything to tempest if it's just going to be as unstable without fixing the root cause
20:30:32 <david-lyle> well the login test never fails
20:30:40 <david-lyle> unless it really should :)
20:30:43 <david-lyle> which is rare
20:30:56 <robcresswell> r1chardj0n3s: Either way, I think there would be more value in having new people look into other options at this stage. The learning curve with the current setup is quite high
20:31:08 <robcresswell> Also, I rarely see the tempest test randomly fail :p
20:31:22 <tqtran> thats because we have like one test in tempest
20:31:33 <david-lyle> best test ever
20:31:33 <r1chardj0n3s> we have precisely one test in tempest ;-)
20:31:42 <david-lyle> a scenario test yes
20:31:46 <robcresswell> My point was that the setup doesnt collapse
20:32:19 <r1chardj0n3s> ok, we have a couple of folks who are willing to get up to speed on our setup to try to fix it, can we agree to leave the disucssion until they've had a look at it?
20:32:22 <david-lyle> people maintain tempest, rolling our own demon spawn testing suite is silly
20:32:29 <david-lyle> no
20:32:34 <robcresswell> And there's likely to be more support on adding tempest tests, that hz integration tests, which has precisely one support person right now
20:32:36 <david-lyle> you're wasting their time
20:33:17 <robcresswell> Agree with Dave here
20:33:20 <david-lyle> I previously was a huge advocate of the integration tests, but the reality has proven it's a lost cause
20:33:36 <r1chardj0n3s> ok, so delete our current integration and selenium tests and start from scratch
20:33:41 <robcresswell> Mirantis had half a dozen people on them at the start of last(?) cycle
20:33:44 <tqtran> +1
20:33:47 <david-lyle> that work started before either of you even started on horizon and they have never been stable for any duration
20:34:01 <david-lyle> selenium is different
20:34:05 <tqtran> scrap it and start new, i like that plan
20:34:10 <david-lyle> don't conflate the two
20:34:12 <robcresswell> tqtran: >.<
20:34:17 <r1chardj0n3s> david-lyle: aren't we the only consumers of selenium in tempest?
20:34:47 <r1chardj0n3s> david-lyle: the integration tests and selenium tests in our code use the same testing framework
20:35:00 <david-lyle> but one is stable and one is not
20:35:15 <r1chardj0n3s> becase?
20:35:16 <david-lyle> plus we have unit tests that run in selenium and those don't fail either
20:35:35 <r1chardj0n3s> yep
20:35:45 <david-lyle> removing integration tests will effect sahara
20:35:51 <david-lyle> I think they have one or two
20:36:19 <david-lyle> unless they have removed them already
20:37:06 <david-lyle> so our Selenium tests in the unit tests will hit mocked API calls
20:37:18 <david-lyle> the tempest one should hit a devstack instance
20:37:25 <r1chardj0n3s> yes
20:37:30 <david-lyle> tempest and integration are the closest parallel
20:38:02 <r1chardj0n3s> ok, so it sounds like there's general enthusiasm for deleting that set of deck chairs and creating some new tempest ones :-)
20:38:23 <robcresswell> At the very least, have a look at tempest before throwing bodies at the current build.
20:38:32 <tqtran> question, so if we go down the tempest route, are we going to bring selenium with us? or will tempest provide all the things we need?
20:38:43 <david-lyle> since we have the plugin now, we can add tests without worrying about breaking the world
20:39:03 <david-lyle> selenium is present in tempest I believe
20:39:06 <r1chardj0n3s> david-lyle: are you able to get ediardo and lcastell up to speed on tempesting?
20:39:23 <tqtran> oh neato
20:39:27 <david-lyle> yes my knowledge runs very deep :P
20:39:32 <r1chardj0n3s> erm, you've been asserting that sleenium is in tempest...
20:39:40 <david-lyle> I think so
20:40:49 <david-lyle> I created the plugin and maintain the test, so yes I'm the closest thing we have to an expert
20:40:58 <robcresswell> \o/
20:41:02 <tqtran> btw, is the horizon tempest repo own by horizon drivers?
20:41:08 <lcastell> bring the knowledge
20:41:08 <david-lyle> yes
20:41:16 <david-lyle> tqtran:  ^^
20:41:22 <r1chardj0n3s> david-lyle: do you have a quick linky to that repos pls?
20:41:28 <david-lyle> but I just +2+A stuff I put in there
20:41:37 <david-lyle> cause
20:41:42 <tqtran> hm ok, im not seeing it on launchpad (but i trust you)
20:42:26 <david-lyle> https://github.com/openstack/tempest-horizon
20:42:52 <r1chardj0n3s> thanks david-lyle
20:43:11 <r1chardj0n3s> so, microversions?
20:43:18 <robcresswell> Right
20:43:34 <robcresswell> I can't really read the word microversion without getting angry any more
20:43:36 <david-lyle> tqtran: https://review.openstack.org/#/admin/projects/openstack/tempest-horizon,access
20:43:49 <david-lyle> haha
20:43:55 <david-lyle> you're welcome robcresswell
20:44:04 <robcresswell> I'm personally still voting for fixed versions in a list in Horizon
20:44:27 <r1chardj0n3s> one of the big issues is that we were considering allowing version exclusions in our local specification of versions that work
20:44:37 <tqtran> i also think a fixed version is going to make life easier for us down the stretch
20:44:40 <robcresswell> Because microversions are designed for users to know what version they want, and just hit that version
20:45:00 * ducttape_ is looking forward to tempest having microversions
20:45:05 <robcresswell> so range may break randomly, and range/exclude is troublesome for the reasons you outlined in the etherpad r1chardj0n3s
20:45:35 <robcresswell> So, I think we should just stick to a list of known functional versions
20:45:43 <robcresswell> like [3.11, 3.18]
20:45:49 <r1chardj0n3s> but you were arguing against that because maintenance?
20:46:02 <robcresswell> Indeed
20:46:15 <robcresswell> I've transcended arguing to the point where I can just  argue myself into a corner alone now
20:46:25 <r1chardj0n3s> whereas we can just get the version range from the target service's source code
20:46:29 <robcresswell> But I think that list of fixed versions is least shit situation
20:47:18 <robcresswell> er
20:47:21 * robcresswell thinks
20:47:25 <rhagarty_> version each resource?
20:47:39 <r1chardj0n3s> rhagarty_: sorry, expand on that idea please?
20:47:48 <robcresswell> rhagarty_: It goes way beyond that, we need to version every feature.
20:47:52 <rhagarty_> most resources will always continue to work, with latest
20:47:56 <david-lyle> I think we should be naive and let it fail
20:48:13 <david-lyle> unless we find something breaking then put some logic in
20:48:25 <ducttape_> +1
20:48:41 <david-lyle> we don't keep up with the APIs now
20:48:49 <r1chardj0n3s> david-lyle: could you be more explicit? how should we be naive?
20:48:53 <ducttape_> this is not all that different from policy
20:48:59 <david-lyle> and now we're going to validate every nuance of microversion role?
20:49:18 <david-lyle> assume API calls will work :)
20:49:24 <ducttape_> write / ship code with little to no checks on micro versions
20:49:34 <david-lyle> there will be a min version for some
20:49:43 <david-lyle> but latest should work in almost all cases
20:49:49 <david-lyle> ducttape_: ++
20:50:01 <rhagarty_> but we need to handle new features introduced in microversions... or we just don't suport?
20:50:06 <david-lyle> the glaring exception will require code changes via bug fixes
20:50:10 <ducttape_> the only problem, is that this will build up over time, on the min versions etc
20:50:43 <robcresswell> rhagarty_: Well, that would be accounted for by a minimum
20:50:53 <david-lyle> most now don't have a min
20:50:57 <ducttape_> david-lyle - what if someone is adding a new horizon thing, and they place a min check, on something that is not in a released service yet ?
20:51:05 <robcresswell> As in, if service.latest is > minimum, show it, and pray it still works
20:51:06 <david-lyle> just the newest additions (in our code base)
20:51:20 <robcresswell> ducttape_: Well, it just wouldnt show up
20:51:29 <ducttape_> I think the reviewers might want to have a rule on that tho
20:51:29 <david-lyle> the result wouldn't show
20:51:33 <david-lyle> log it
20:51:46 <robcresswell> The problem with this is that Horizon could break in fun and unnoticed ways
20:51:47 <ducttape_> like don't merge code unless this feature is in a release somewhere
20:51:51 <rhagarty_> resullt would show... with errors
20:51:57 <david-lyle> ducttape_: ++
20:51:59 <r1chardj0n3s> a problem with ignoring microversions is that it means we could probably never implement something https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/migrate_server.py#L65
20:52:52 <ducttape_> nah we can add new things, and have them use a min ---   this is fine / ok I think
20:52:52 <david-lyle> that looks like a disaster
20:52:52 <r1chardj0n3s> not that I dream of implementing against an API that mutates every few versions...
20:52:53 <robcresswell> ARGH WHO THOUGHT THIS WAS SMART
20:52:57 <robcresswell> fuck sake.
20:53:15 <rdopiera> nova...
20:53:24 <ducttape_> holy shit that link is hurrible
20:53:36 <r1chardj0n3s> "someone else's problem"
20:53:42 <ducttape_> r1chardj0n3s we now feel very bad about ourselves   ;)
20:53:49 <robcresswell> stability is hard, lets push this on to the users and consumers.
20:54:14 <r1chardj0n3s> so, the point is, that for *some* API calls, we will need mivroversion support
20:54:20 <ducttape_> agree
20:54:25 <david-lyle> or say this is too stupid
20:54:34 <david-lyle> we abstain
20:54:37 <robcresswell> hahaha
20:54:39 <r1chardj0n3s> I have proposed that we pull the version ranges directly from the service itself (we can grep to find most of the information)
20:54:39 <tqtran> lol
20:54:40 <rhagarty_> cinder likes it... it forces user to specify version in CLI calls, which they can live with. They didn't think through/care about Horizon
20:54:41 <ducttape_> I think david-lyle and I are saying - avoid the micro version stuff unless you are really painted in a corner
20:54:53 <r1chardj0n3s> ducttape_: and I'm agreeing
20:55:00 <rhagarty_> I am painted in a corner
20:55:01 <r1chardj0n3s> we already have one patch up that needs microversion support
20:55:03 <robcresswell> rhagarty_: Or about anyone not using a CLI
20:55:26 <r1chardj0n3s> so we need to make sure our approach is sensible (or at least starts out with something that we think is sensible)
20:55:39 <robcresswell> r1chardj0n3s: So, minimum and *optional* maximum?
20:55:40 <ducttape_> we are not starting from a sensible place  ;)
20:55:46 <r1chardj0n3s> robcresswell: yes
20:56:01 <david-lyle> we still have the vague concept of an integrated release
20:56:04 <rhagarty_> I added cinder consistency groups, which goes away in 4.0. It is being replaced by generic groups, added in 3.13, 3.14 and generic group snapshots added in 3.15
20:56:24 <david-lyle> as long as we support the latest MV in those releases, I think that handles most of  it
20:56:25 <r1chardj0n3s> we have four minutes to go
20:56:32 <r1chardj0n3s> #topic Mascot
20:56:35 <r1chardj0n3s> just quickly
20:56:45 <robcresswell> Right, I'll update the bp to specify minimum and optional maximum
20:56:47 <ediardo> Very Mascot
20:56:47 <david-lyle> the legacy of backward compatibility may be lost to microversion purgatory
20:56:50 <ducttape_> did robcresswell get images ?
20:57:03 <david-lyle> ducttape_: on the MML
20:57:03 <robcresswell> did I what now
20:57:04 <r1chardj0n3s> I really like rdopiera's reworking of the mascot, and weill be feeding that back to them
20:57:05 <david-lyle> *ML
20:57:16 <david-lyle> r1chardj0n3s: ++
20:57:20 <robcresswell> Yeah, it should be orange and white
20:57:21 * ducttape_ avoids the ml, heads there now
20:57:24 <robcresswell> not a husky
20:57:27 <r1chardj0n3s> yep
20:57:29 <david-lyle> rdopiera: did you provide that as feedback on the link?
20:57:32 <robcresswell> its basically identical to the release one I think
20:57:40 <david-lyle> ducttape_: sorry
20:58:08 <rdopiera> david-lyle: what link?
20:58:25 <robcresswell> Oh, I threw another tantrum on twitter at the foundation and the updated me on the logo's to say it'll still be another few weeks to make an svg -.- so I'll probably do it myself
20:58:28 <david-lyle> feedback link for the mascot
20:58:35 <r1chardj0n3s> robcresswell: \o/
20:58:52 <rdopiera> david-lyle: I saw no feedback link, just the image as an attachment
20:59:15 <r1chardj0n3s> I didn't include the feedback link in my message because I actually don't know what it is ;-)
20:59:24 <david-lyle> oh r1chardj0n3s didn't include that part of the email
20:59:42 <david-lyle> I bet he will now
20:59:42 <rdopiera> so in short, no
20:59:45 <david-lyle> :)
20:59:47 <r1chardj0n3s> www.tinyurl.com/OSmascot
20:59:54 <r1chardj0n3s> is the feedback link
20:59:59 <r1chardj0n3s> thanks everyone! time's up
21:00:03 <r1chardj0n3s> #endmeeting