[01:50] Can anyone tell me if configuration options are changed after deployment of an openstack charm, if that information will automatically get updated in the database? As an example, will changing the VIP update the keystone endpoint list in the DB? === negronjl is now known as negronjl-afk [04:02] designated: it should [04:03] designated: however, there are a few configuration options that are immutable, I don't think that is one of them though === lamont` is now known as lamont [10:54] hey === frankban__ is now known as frankban [12:24] Can I get a peer unit's public-address ? [12:25] Hmm... I guess I can set it myself on the peer relation [13:21] stub: you'd have to set it on the wire [13:21] as you allueded to === kadams54 is now known as kadams54-away === negronjl-afk is now known as negronjl === kadams54-away is now known as kadams54 === mwak_ is now known as mwak === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [15:39] marcoceppi_: ping. [16:02] rick_h_: happy new year! the store is out of date with bzr for https://jujucharms.com/landscape-client/trusty/10 and https://jujucharms.com/landscape-client/precise -- there are two more revisions for each [16:04] dpb1: otp will look [16:06] dpb1 did I see you committed changes to the landscape charm to fix automated testing errors? [16:07] mbruzek: yes [16:08] dpb1 it is a happy new year [16:08] hah [16:08] :) [16:19] \o/ === roadmr is now known as roadmr_afk === roadmr_afk is now known as roadmr [18:22] logistics question. I've never submited MR for a charm. and also haven't used bzr much. do people prefer getting small logical MR for something, or is that a pain due to the review process? [18:23] e.g. I want submit 2 changes in how pip is handled to the python django charm. 1. support extra args for pip. 2. stop using deprecated options [18:24] in some projects, it would be the custom to submit those separately, what is the preference here? [18:25] skay: small chunks are fine for MR's [18:25] you can make chained dependencies on Merge proposals [18:25] the smaller the change, the more likely it is to be merged fairly quickly [18:25] thanks lazyPower, I like small changes. (I didn't know about the chained thing) [18:38] I forgot where in the docs it lists which config types are allowed. I would like to use a list, but I can't remember if that's allowed [18:38] right now I do a split on ' ' or ',' in some places, and a list would probably be more natural [18:39] oh derp. I found it. sorry for the trigger happy question === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [18:46] rick_h_: gentle ping reminder. :) [18:46] dpb1: yes, just finished phone calls and starting to look. [18:46] ty [18:46] dpb1: will be out first time using out fancy ingestion log so looking up how we can use it. [18:47] oooh, hopefully it's easier this time! [19:11] dpb1: these were updated a while ago? [19:12] let me check the revno [19:12] looks like back mid-dec [19:12] ya, sounds right [19:12] trying to see how far back I can get logs for [19:12] logging every 15min means that's a while back [19:12] :) [19:12] did find this for you as an fyi https://pastebin.canonical.com/122931/ [19:24] rick_h_: ok... will look at that as I work up the stack [19:27] dpb1: well the good news is I found the logs from that timeframe [19:27] dpb1: the bad news is that I don't see any reference to your charms in any warning/error logs so no closer to knowing wtf [19:28] :( [19:28] dpb1: so creating a card and will get it assigned to chase it down but probably more time than a quick "oh, there's your problem" [19:29] rick_h_: ok, thanks for looking. it's not super urgent, as long as we get it fixed. [19:29] promise that === roadmr is now known as roadmr_afk === kadams54_ is now known as kadams54-away === kadams54-away is now known as kadams54_ === kadams54_ is now known as kadams54-away [20:23] \o/ yay, I submitted a small merge request for python-django. [20:23] does the ci job get kicked off automatically, or do I need to ask for it here? === roadmr_afk is now known as roadmr === kadams54-away is now known as kadams54_ [20:39] anyone: I've got a PR to juju-solutions.github.io to add a containers page if someone wants to ack it pls. [21:48] skay: it'll be kicked off by whoever is doing review [21:49] marcoceppi_: mbruzek: https://bugs.launchpad.net/juju-core/+bug/1408467 [21:49] Bug #1408467: juju help-tool does not reflect all options available to relation-set

[21:50] Oh I hate that bug! [21:50] We should fix that one! [21:51] bah, what a horrid bug! [22:03] learning to write charms following tutorial found on web [22:03] can create/launch the demo wordpress [22:04] would like to log into container [22:04] johnny_shieh: if you dont mind me asking, which tutorial are you following? [22:04] but ssh fails with permissions issue. [22:04] johnny_shieh: try doing juju ssh service/# [22:04] eg: juju ssh wordpress/0 [22:04] https://juju.ubuntu.com/docs/ [22:05] hmmm, let me try [22:05] https://bugs.launchpad.net/juju-gui/+bug/1408472 [22:05] Bug #1408472: The juju-run command on the unit does not have help

[22:05] Oo another one! [22:05] we should fix that one too [22:05] I know! ... Right?! [22:06] thanks lazyPower [22:06] worked [22:06] * lazyPower hat tips [22:07] thx for help, be back in a few days with actual, real problems. ha-ha [22:11] * arosales heads over to the review can for some review time. [22:11] s/can/queue [22:12] marcoceppi_: mbruzek: any ideas/opions on how we should handle the MPs for tests that are currently failing auto test? [22:12] marcoceppi_: mbruzek: I presume these are due to the charm and not the test as the charm tests do not touch the charm code. [22:13] it seems like it would be good to have these tests included in a charm that failing. Specifically, when someone comes along to fix it then can run the tests and have seed tests to build off from. [22:13] arosales: tvansteenburgh had some strong opinions [22:13] on this subject. [22:14] arosales: I reluctantly agree with you and tvansteenburgh [22:14] But that still feels "bad" [22:15] mbruzek: is the concern that the charm is failing auto charm testing but the MP is still accepted? [22:15] arosales: yes because that sets a bad precedent, other folks are going to ask them to merge their changes while the tests STILL fail [22:17] mbruzek: I see that point. Whats interesting here is that for tests they don't touch charm code. [22:17] and in the case for failing tests adding tests actaully may help debug the charm. [22:17] arosales: agreed [22:17] my opinion is that it helps get the charm into a better passing state [22:17] so the decision is to nack or ack the MP [22:18] on the one had if you nack, then the next person doesn't have seed tests or a charm tests to run against the charm to see what the failure was [22:18] on the other hand if you ack, then at least the next person has a test to run and try to reproduce and a seed test to build off from. [22:18] * arosales 2 cents [22:19] arosales: we already get requests to merge MPs that fail charm proof, or other minor problems that "the change did not touch" [22:19] are those tests or charm code? [22:20] jose, dbp, marcoceppi_, mbruzek, lazyPower, niedbalski, tvansteenburgh, lazyPower: any opinons ^ [22:20] charm code, that someone is adding, they say since they didn't make the charm proof any worse they want their MP merged [22:21] its a fair question and good point for not accepting the charm test. [22:21] if adding tests to to a charm that has none, i'd merge even if they fail [22:21] b/c at least now we know there's a problem [22:21] my 2 cents is that the charm tests actaully help get the charm into a good state (passing tests) and thus should be accepted there. A charm code MP may not be able to state that, in general. [22:21] arosales: to be clear I agree with you and tvansteenburgh, we should merge the failing tests [22:22] mbruzek: I appreciate you are trying to weight both sides. [22:22] My proposal is to get a few charms, at least 3, to agree so we can clear out the queue with these MPs. [22:23] been in there far too long [22:23] so two charmers +1 any others? [22:23] we should resume this conversation when marcoceppi_ has a chance to comment. I suspect he has strong feelings one way or the other. [22:23] * mbruzek believe marcoceppi_ is eating now. [22:25] the force is strong with that one [22:25] he agrees [22:25] * arosales pinged other charmers too [22:25] at least the ones I could recall. [22:26] * arosales will wait patiently [22:26] tvansteenburgh: mbruzek: in the mean time is there any thing I can to to help wth those MPs? [22:26] leave a comment in them or does a charmer just need to take action on them once the decsion is made? [22:27] pull requests to fix why the test is failing [22:27] In the end that is what we are after [22:27] :) [22:27] lol mbruzek [22:27] nice one [22:27] You can pull request against me or marco's branch to fix the test [22:27] or pull request against the charm. [22:28] understood :-) [22:34] marcoceppi_: when you return, for lp 1387465 can you let me now what action is needed to get this item out of the queue? [22:34] marcoceppi_: same thing for 1387467 [22:40] * arosales taking a +1 look @ 1396237 [22:44] wat === kadams54 is now known as kadams54-away [22:47] lazyPower: brain dump to follow... [22:47] mbruzek: ^ [22:49] what we have: maas node with 2ea openvpn-server charms and 1 openvpn-p2p charm forced onto one node (along with a few subordinates). the other side of the p2p link is outside of maas/juju, as is the entire pki infra. ergo, the openvpn-server and p2p charms have a bunch of config vars to delvier ca.crt and host key/cert and such [22:49] which makes reading/deploying the charms problematic for someone using just juju (no PKI wat?) [22:50] enter the openvpn-pki charm, which optionally relates to the other 2, and provides a PKI infra (most notably, today it delivers the ssh pubkey and IP address that will be doing the syncing) [22:51] currently coded as "when this relation comes up, dump some config vars into a file on the unit, and silently override the juju config variables with the actual answers from the openvpn-pki unit) [22:51] lamont: i can understand the situation you're trying to solve - however relationship data should not overwrite config data coming from teh user - that alone would get a nack on a charm review. My thoughts would be if you have a third party PKI utility - it should either proxy the information in from your existing infra, or allow those bits to be set by the user, that way the onus of where the config is coming from is not on the openvpn server [22:51] itself but on the PKI charm you're relating to the unit. In which case - depending on if its coming from a proxy or being set by the user is dependent on how the charm is deployed [22:51] which is vomitworthy [22:51] and you could then send that information via the relationship to openvpn and not worry about this [22:53] this way both scenarios are modeled in the juju language, and both are actionable [22:53] So lamont what happens to the ca.cert if the user sets a ca.cert on the openvpn charm and then the openvpn-pki charm comes by with a different ca.cert? [22:53] you can then say "if user config data" is present, that will override any relationship data - so it follows the juju tenants, and if that data is not present, it sends the data from the proxy [22:54] I was just thinking... how horrible would it be to have the charm behave correctly, and then have a subordinate charm that eliminates the need for a relationship to openvpn-pki? [22:54] a subordinate woudl be a fine approach too - you dont necessarily need to tie up a unit for data-pass [22:54] actually - a sub would be the preferred route forward [22:54] mbruzek: as it sits, openvpn-pki wins: code says "conf = config(); if-file-exists { read yaml and overwrite into conf}' [22:55] lamont that would break the user experience. [22:55] mbruzek: hence the "how much would you guys scream" that brought me here... [22:55] lamont: <3 [22:56] lamont: if a user sets something with config-set or from the gui we should do EVERYTHING possible to preserve that [22:57] if I understand this, the correct solution is: openvpn-pki <-> openvpn-{server,p2p} quietly delivers the info over the relation (and server/p2p spill it to a file which is used in config), and an "openvpn-external-pki" subordinate provides all of the variables for juju set to let a non-juju pki be used instead of the charm. [22:57] Making the user know/care about the order of charms deployed is ALWAYS a "bad idea" [22:57] and server/p2p do not have settable variables for the pki meta [22:58] mbruzek: If it helps, I was feeling dirty. [22:58] lamont: that soudns correct to me in the ascii diagram above - the subordinate allows for you to either proxy the info in or configure it, correct? [22:58] lamont: clean your self up this is a family show. [22:58] it felt _wrong_, which led me to seek help [22:59] so that summary sounds right? [22:59] lamont: Yes I like you ascii diagram solution [22:59] ascii ftw [22:59] all of which means I have my work cut out for me. [22:59] lamont: dont' forget to write the README.md too. [23:00] and stupid question: subordinate charms... will I need a relationship there, too? [23:00] The openvpn-p2p readme was VERY sparse [23:00] well, *good* charms can be difficult to write as complexity grows. but a bundle/bundle(s) will make this simple for users to get setup and moving with, and we'll give you much fanfare when it lands [23:00] mbruzek: there is this significant feedback item about how terse (or, conversely, verbose) my explanations are. working onit. [23:01] lamont: expect some blogging / an instructional video when it lands tho - we'll give ya the red carpet for your efforts. [23:01] lamont: subordinate charms relate on the juju-info relationship to a container charm (non subordinate) [23:01] * lamont still gets grief from a former coworker from many years ago for a program of several hundred lines, with the singular comment "do stuff" in it. [23:01] lamont: so you get the subordinate relationship for "free" [23:02] lamont: at least it wasn't misleading or incorrect, right? :) [23:02] mbruzek: for the charm writer of poor literacy.... does that mean that config() in the container charm returns the set variables from the subordinate? [23:03] lamont: something that lazyPower and I talked about just *today* was that subordinates can have peers too, so one subordinate can be related to different container charms and the subordinates can use the peer relation [23:03] sarnold: fact [23:03] actually, hrm. [23:03] sarnold: *rimshots* [23:03] o/ [23:03] hehe do stuff [23:03] sarnold: it's from the "self documenting code" era [23:04] I like "read my mind and do what I want" [23:04] lamont: re: your question to mbruzek - no, config() will continue to only return the config data from that charm. Data being sent over the wire is in relation-get [23:04] sarnold: that code used a 400MB (yes, MB) disk to transfer files between a un*x box and a non-un*x box. beacuse of reasons [23:05] lazyPower: and the relation is "just there" by right of the subordination? [23:05] lamont: now we're talking about interfaces and properly consuming/documenting interfaces+data in the readme/contributing documents. But when you get to that point, feel free to tap me in and i'll help. [23:05] you define it by every variable you send OTW via relation-set [23:05] lamont: at least it wasn't "literate programming".. I'll take self-documenting code any day :) [23:05] this is why its super important to document it, otherwise users have to read teh code to know what its doing, and we as charmers will hate you forever. we already have a truckload of interfaces to document [23:05] lamont: re: config - No the subordinate configuration are not in the container charm's config [23:05] lazyPower: I'm guessing that I still need Provides/Requires? [23:06] lamont: thats depreciated, its the wild west with interfaces - no forced gets/sets [23:06] * lamont drops the side conversation with sarnold. :p [23:06] its even been removed from the documentation [23:06] you just arbitrarily set them, and consume them [23:06] skay: sounds about right :D [23:06] ok. this'll be fun. :D [23:07] config-changed only triggers on juju set, correct? [23:07] config-changed triggers when the charm config changed [23:07] so 'yes' to juju-set triggering it [23:07] but it also runs after install and upgrade-charm [23:07] lamont: don't forget the gui [23:08] mbruzek: right. was thinking api-speak. [23:08] relation-name-changed triggers when relation-set is called on any of teh charms in the relationship chain "do stuff" that sets a variable. [23:08] sometimes, I hate computers [23:08] lazyPower: and (duh) relation-setting doesn't trigger config-changed [23:09] is it true that both hooks will never run concurrently? (only one hook to a unit, at a time, yes?) [23:09] correct [23:10] what I really want is a juju status item that says "and no hooks are queued or running at this time" [23:10] (though there could be one queued/starting right after the status, don't care) [23:10] lamont: we all want that. its a work item in the near cycle(s) to get better information from status about whats going on in the unit [23:11] \o/ [23:11] with that, time to go rewrite some charms. [23:14] lamont: all the best o/ cheers [23:20] example of a subordinate charm that does things by the new /current method? [23:21] lamont: one doesn't exist as we dont have many/any ['proxy','configurable'] subordinates that I'm aware of. But again, tap me in and I can help when you get to writing the hooks [23:22] and/or planning of said charm [23:22] ah, well... that'd be "about now", since it basically consists of ripping out a bunch of config vars from openvpn-serfver and creating said charm. [23:22] here, or /pm? [23:23] Lets do it here so others can benefit from our riffing [23:24] ok. [23:24] categories: [23:24] - misc [23:24] subordinate: true [23:24] :D [23:24] you'll need to add a requires relation that is scope: container [23:24] https://juju.ubuntu.com/docs/authors-subordinate-services.html [23:25] requires: [23:25] openvpn-pki-recipient: [23:25] interface: openvpn-pki-sync [23:25] scope: container [23:25] cool [23:25] ok, so you've now got an openvpn-pki-recipient ['joined','changed','broken','departed'] relationship on both sides [23:25] the subordinate unit itself shoudl relation-set the relevant parts, if its coming from proxy or from user config (possibly both are user config, depends on how you build it) [23:26] and the openvpn-pki-recipient service itself will need to consume whats being sent via relation-set [23:26] mbruzek: why is lp 1408472 targeted at juju-gui? [23:26] seem straight forward enough? [23:26] (so far anyway) [23:26] lazyPower: yep [23:26] ta [23:27] lazyPower: any opinions on the earlier conversation on approving MPs that only add tests even though the charm is failing those tests? [23:27] in config-changed (yes), how do I find the relations(s) to do the relation-set calls? (python, with charmhelpers) [23:27] marcoceppi_: because I made a mistake [23:28] lazyPower: (in a clean/current way - I'm learning that nagios-external-master is not a charm to crib from) [23:28] no [23:29] arosales: I just linked a new branch and initiated tests against the new branch so that we can know if it passes or not for 1387465. 1387467 needs another test run executed. I just queued it up [23:29] lamont: we have several flagbearer charms [23:29] mbruzek: <3 [23:29] mbruzek: fyi - rails is not one of them, i've gone back through and started re-working that one, so anyone asking about chef - send them to me direct until I can get the charm reworked and the docs updated to reflect the new pattern i'm working on. [23:30] arosales: I'm a plus one, but we have another issue steming from that. Whos responsible to fix that? Should we hault all further changes to that branch until someone fixes it? or just keep merging things that address issues even though the tests continually fail [23:30] marcoceppi_: once those tests are done for 1387465 and 1387467 will those fall out ofthe queue. Seems odd they are still in the queue even though the bug is marked as "Fix Released" [23:30] lamont: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-s-juju-flag-bearer-charms [23:31] ta [23:31] arosales: that is weird. [23:31] personally I recommend the lamp charm for the tests, but I don't remember if the _charm_ code is any good [23:31] arosales: one sec [23:31] marcoceppi_: in regards to charm tests. Per policy https://jujucharms.com/docs/charm-unmaintained-process [23:31] * mbruzek knows the tests are "awesome" because he wrote them. [23:32] That is all from me tonight, I have guests coming over and need to go for the evening. [23:32] oh nice - rails didnt make the list. <3 [23:32] if the charm continues to fail tests (ie deploy is broken) then it becomes a candidate to move into un-maintained if no action is take on it to fix it [23:32] * mbruzek waves [23:32] i'll get that fixored eventually [23:32] arosales: how long is that period after we start accepting contributions? anotehr 15 day grace period? [23:32] arosales: fixed [23:33] marcoceppi_: thanks I don't see them in the queue anymore [23:33] lazyPower: sorry I didn't properly parse your question [23:34] * marcoceppi_ decides to do a bunch of fixes to the review queue tonight [23:34] lazyPower: in regards to unmaintained charms; if a bug is logged against a charm and no action is taken to fix it 1 month after the bug is failed the charm will then be moved into the unmaintained branch. === marcoceppi_ is now known as marcoceppi [23:35] arosales: right - but you were saying if the tests continually fail [23:35] at this point, we know there is an issue with the charm when we start accepting these contributions cognisent of them having failing tests [23:35] lazyPower: ah [23:35] it doesn't seem right to just merge that in and reset the countdown timer on unmaintained. Maybe i'm being a stickler though [23:35] the way I read policy is that if active work is going on in the charm then the charm is not a candidate for unmaintained [23:36] the issue is when there is a bug against a charm and no work is being done to address it [23:36] 10-4 [23:36] so if i'm reading htis properly - we file a bug about the failing test [23:36] if nobody comes around to fix that, but they keep adding MP's we just ignore the failing test for the time being until someone gets around to fixing it [23:36] currently auto testing will only run against a charm when there is a MP agaist it which would signal an effort to bring the charm into good standing. [23:37] ok, i mean seems fair enough as we dont really know what the community at large will do with this information against their charms, we only have a handfull right now failing tests right? ~ 30 or so? [23:37] or am i looking at the wrong data sheet [23:38] ya, I think it was around 30 [23:38] I hope to add failing charms in to the review queue soon [23:38] as a section [23:38] marcoceppi: <3 you and the rev queue magic, all the new queues and what not [23:38] yeah...as soon as they show up...one day [23:38] marcoceppi: i have an idea that we kind of riffed out tonight about the store + recommended that I want to send to teh charmers team for pre-feedback in the near future [23:38] lazyPower: okay, there is the monthly thingy [23:38] it will address a few different areas that we're experiencing pain in one move [23:38] we are still doing that? [23:39] i thought we didnt want to do that [23:39] lazyPower: so to mbruzek's earlier point if an MP comes in and touches charm code but the charm tests are failing a charmer would need to decide if that MP should be accepted [23:39] lazyPower: so I don't think we should ignore the failing tests [23:39] arosales: i'll put on my "take me seriously hat" and put googley eyes on the review about the tests. [23:39] but what we shouldn't do is move the charm into unmainted as there is "active" work on it. [23:39] yeah, i'm +1 for that... We already have a high bar for getting into recommended status [23:40] if we just start nuking charms because we have a stickler for tests, we will be alienating people working [23:40] ya moving to unmaintained is really a last resort when a charm is broken and there is zero work to bring the charm back to a working state. [23:41] * lazyPower recalls there being a yoda image at one point that summed it up nicely [23:41] the thought being that the recommeded charm store should always have charms that are in a working state or at least a state of being fixed [23:41] well i'm a fan of ~recommended being the de-facto best of the best [23:42] namespaces are around for the rest, for in-dev, community love, and development focus [23:42] so lazyPower marcoceppi: my original question to the charmers team is do you guys agree the oustanding MPs in the queue to add tests should be accepted even though the charm is failing tests? [23:42] but this is starting to touch on what i want to riff with marcoceppi and other ~charmers about - kind of our curation process and bits - but it is goign to take a lot fo fleshing out as i'm sur ei've got gaps in what i'm thinking. [23:43] my comment was that the tests actually help get the charm fixed as it provides a reproducibile failing environment, and add seed tests to the next person wanting to improve the charm. Plus the tests don't touch charm code. [23:43] arosales: I agree, but with reservations [23:43] arosales: yeah, if there's work going on towards a charm - and it doesnt effect the tests - file a bug against the charm about tests and move on [23:43] keep making it happen [23:43] marco will have a test failure queue soon(ish) that we can address when we have more info about longevity of a charms failure rates [23:43] lazyPower: in this case we don't know if there is work on the charm outside of the tests [23:44] we only know that marcoceppi and mbruzek added seed tests to charms [23:44] welp, getting the tests in there is the first step right? [23:44] some of those charms fail the tests [23:44] so we got a load of those in the charm queue [23:44] seems wrong to stop progress at step 1 if we have a course of action to completion [23:44] and we just need to make a decision to nack or ack those [23:44] I was going to say it's the author of the tests job to fix the charm [23:44] then I realized how much more work that was for me [23:44] and decided to not say that [23:44] except right then [23:44] lazyPower: agreed [23:44] when I said it [23:45] arosales: because that basically says "We gave basic deploy tests, and its failing - so due dilligence is needed. No maintainers in 30 days step up? time to hit the eject button" [23:45] this will do a couple things [23:45] ditch some old charms people dont want to undertake updating, and give us metrics to empower the decision [23:45] and i'm all for making data driven decisions [23:45] lazyPower: ya I agree it helps get the charm into a fixed state by first identiying there is a problem [23:46] arosales: so, can we make that the workflow? file a bug after the MP lands with the failing est [23:46] thus my proposal is for the charmers to accept charm tests even if the charm is failing those tests [23:46] and that kicks off the countdown timer [23:46] arosales: i'll be happy to go through and verify everything that i run across during review time if you leave a breadcrumb trail that its been filed and identified as a failure [23:46] and we can pass off a notice to other charmers that this is what we are donig [23:46] *doing [23:47] lazyPower: so all the charms @ http://review.juju.solutions/ [23:47] arosales: woo all of them are failing? hooo boy [23:47] * lazyPower puts on his firemans hat [23:47] from mbruzek and marcoceppi with "add-tests" or "tests" branch are what need approval [23:47] 10-4 [23:47] if you pre-triage i'll follow behind you before i EOD or first thing tomorrow [23:47] i still owe for review this week - i managed to miss my slot on Tuesday [23:47] also tvansteenburgh and mbruzek +1ed accepting these tests [23:47] jsut wanted at least charmers to +1 [23:48] yeah, still need votes from jose, dpb1, and niedbalski if they are around and want to chime in [23:48] but i'm all for it [23:48] so if lazyPower and marcoceppi +1 then it sounds like it ok for your to accept these tests for the above reasons [23:48] you sold me, good salesmanship [23:48] * arosales already pinged them ealier [23:48] ah, then we'll silently discard those votes if they are negative ;) [23:49] no replies yet [23:49] <3 if they read scrollback [23:49] well you have the majority of charmers +1ing it [23:49] but I would be interested to hear an objection if there is one [23:50] yeah i'm just being obtuse. its late in the day. [23:50] * lazyPower goes back to hacking on subordinate logic [23:50] lazyPower: I am happy to traige those test MP, what specific action do you need from me a +1 on the syntax of the charm tests? [23:51] I would say that, and i'll go through and add bugs to the charms when the MP's land for failing tests [23:51] that way its part of my wrap-up email to the list [23:51] which can serve as day 1 of notice [23:51] 30 days to fix failing tests, unless other active dev is going on - if active dev is going on - they get an extension to fix the tests basically. but it puts us 1 step closer to trimming the warts on the store. [23:52] sounds good [23:52] I am going to finish up my review of OpenID/SSO and then work on the testing MPs [23:52] lazyPower: thanks! [23:52] * lazyPower hat tips