[03:17] <ihashacks> SpamapS: is the mysql-oneway-replication horribly broken like Nagios was or is it just me?
[03:17] <ihashacks> errors: http://paste.ubuntu.com/998416/
[03:18] <ihashacks> running: juju add-relation skydb-master:master skydb-slave:slave
[03:19] <ihashacks> juju status: http://paste.ubuntu.com/998419/
[03:19] <ihashacks> I know that there are settings for "user password hostname port dumpurl" referenced here: https://juju.ubuntu.com/Interfaces/mysql-oneway-replication
[03:19] <ihashacks> Not clear to me if the burden of setting those is on me or the relation scripts
[03:23] <JoseeAntonioR> Hi guys! I have a question: if you deploy mysql, do you get a web interface or something?
[03:24] <ihashacks> "deploy mysql" gives you a mysql server that you can "add-relation" to other services such as wordpress for the web part.
[03:25] <JoseeAntonioR> great, thanks
[15:10] <SpamapS> ihashacks: mysql-onewa-replication should work in theory.. but like the nagios charm, it may have bitrotten since I first created it almost a year ago
[17:06] <jcastro> hazmat: good afternoon!
[17:06] <jcastro> how we looking wrt. the queue page?
[17:07] <SpamapS> jcastro: heh.. negronjl did a nice job producing a cmdline version :)
[17:07] <jcastro> !
[17:07] <jcastro> donde?
[17:07] <SpamapS> jcastro: I'm about to +1 the merge proposal into charm-tools
[17:07] <negronjl> SpamapS: nice :)
[17:07] <jcastro> I was going to ask that next, heh
[17:08] <hazmat> greetings jcastro
[17:08] <hazmat> jcastro, wip
[17:08] <SpamapS> negronjl: threading buys me about 0.5s ... the other 3.5s is all waiting for the bug search :-P
[17:10] <SpamapS> negronjl: merge away, sir
[17:10] <negronjl> SpamapS: thx
[17:11] <jcastro> hey so, by default for ubuntu sponsorship each person does 4h a month
[17:11] <jcastro> obviously we're much smaller
[17:12] <jcastro> so I was thinking going for something like 2 hours a week?
[17:12] <jcastro> for people in ~charmers
[17:12] <jcastro> is that too much/little?
[17:19] <SpamapS> jcastro: I don't think we all have 2 hours a week to give
[17:19] <SpamapS> jcastro: nor does the influx of sponsorship demand 2 hours a week
[17:19] <SpamapS> jcastro: 4 hours, in one block, is more valuable than 2 hours in 4 blocks, IMO.
[17:19] <jcastro> ok so you're thinking once we get past the hump we should just go with that?
[17:20] <SpamapS> jcastro: we don't need 24/7 coverage either.. we just need "most of the day on most days" coverage
[17:20]  * jcastro nods
[17:21] <SpamapS> jcastro: a quick link to the calendar in topic or just on the Charms page would be nice tho.. so you can see when there is coverage
[17:21] <negronjl> jcastro, SpamapS: For the time being, we could concentrate on number of reviews ( say one per person per week )
[17:21] <SpamapS> negronjl: I'm hesitant to change the plan we came up with
[17:21] <jcastro> we have about ~7 people in charmers that have been regular reviewers
[17:21] <SpamapS> negronjl: patch pilot works because it is simple and focused on using peoples' time to maximum effect
[17:22] <jcastro> SpamapS: the topic and calendar and stuff will be easy
[17:22] <negronjl> SpamapS: I'm ok with that.  Let's just pick something.  I threw that suggestion out there because I saw some hesitation to move forward with the current plan.
[17:23] <jcastro> we'll be fine I think
[17:23] <SpamapS> negronjl: only hesitation from jcastro.. ;)
[17:23] <SpamapS> who listens to *that* guy? ;)
[17:23] <jcastro> I have no hesitation, I was just wondering if the # of hours was right
[17:23] <negronjl> SpamapS: not many people :)
[17:27] <SpamapS> jcastro: we have no baseline.. so we can try 4 hrs and measure the effect
[17:31] <jcastro> SpamapS: I was thinking of proposing "everyone all in until we get it under control, then go nice and easy"
[17:35] <SpamapS> jcastro: I've tried that before. Doesn't seem to have much effect. The usual people do their usual awesomeness, then return to not having enough time to address the queue.
[17:36] <SpamapS> jcastro: lets just light the fire of 4 hours per month.. assign people days.. nag them.. and if things aren't getting touched enough, bug people who are in ~charmers to do more.
[17:36] <SpamapS> We have, what, 27 people!?
[17:41] <negronjl> SpamapS, jcastro:  I agree that, with 27 people and no baseline, 4 hours is as good as anything so, for now ... start there.
[17:44] <SpamapS> I would hope that those 27 would be a little more involved with a known time to plan for
[17:50] <negronjl> SpamapS: that makes me think that, the same way that there is a process to become a charmer, there should be one to remove people that are inactive.  Just a thought
[17:53] <SpamapS> negronjl: I'm fine with developing an inactivity report.. we can simply scan the bugs commented on for each user and if there are non in /charms for the past 3 months, warn then remove.
[17:53] <SpamapS> negronjl: Lets make that a TODO for something to add to policy after we get policy in the bzr repo.
[17:53]  * SpamapS opens a charms bug
[17:53] <jcastro> I was just going to mention it in the sponsorship initial mail
[17:54] <jcastro> "if you're in ~charmers and haven't been reviewing you have a few days to get out, otherwise I'll start assigning you and annoying you."
[17:54] <SpamapS> Yeah start seeding now "please participate or flag yourself as not participating so we can set expectations appropriately"
[17:58] <negronjl> jcastro:  Have you created the calendar yet ?
[17:58] <jcastro> nope
[17:59] <jcastro> daniel's script just adds your assignment to your work calendar
[18:00] <SpamapS> jcastro: would be much better if it was a single calendar that people can see
[18:01] <negronjl> jcastro:  I think I like that better as well
[18:01] <jcastro> k
[18:01] <jcastro> I'll figure something out
[18:03] <SpamapS> Ok, filed bug 1002406 for the ~charmers policy
[18:03] <_mup_> Bug #1002406: Add policy to discuss when charmers members should be automatically removed <policy> <Juju Charms Collection:New> < https://launchpad.net/bugs/1002406 >
[18:03] <_mup_> Bug #1002406: Add policy to discuss when charmers members should be automatically removed <policy> <Juju Charms Collection:New> < https://launchpad.net/bugs/1002406 >
[18:03] <SpamapS> Uhhh
[18:04] <SpamapS> twobottux: you need to go away
[18:08] <bkerensa> =o
[18:08] <SpamapS> whose bot is that?
[18:14] <hazmat> twobottux, its an askubuntu bot afaik
[18:14] <hazmat> SpamapS, -> <twobottux> 07:52:48> Announcement from my owner (amithkk): Hey! I'm 2bottuX, A bot by Amith KK. I'm on 2 ubuntu channels and #2buntu. My Function is to provide AskUbuntu Integration. If you want me in any of your channels watching a tag, msg amithkk
[18:14] <hazmat> marcoceppi, ^
[18:15] <hazmat> not sure why its doing lp stuff
[18:21] <SpamapS> Yeah it needs to ignore bugs
[18:22] <SpamapS> otherwise bugs will be 3 lines of spam every time
[18:22] <marcoceppi> hazmat: I'll talk to amithkk
[18:26] <jrgifford> marcoceppi: SpamapS so you need it to ignore bugs?
[18:26] <marcoceppi> jrgifford: yeah, the _mup_ bot already does that
[18:27] <jrgifford> gotcha
[18:27] <marcoceppi> if it's to do anything it should only follow the juju tag on Ask Ubuntuy
[18:27] <jrgifford> ok, let me see if amithkk left the tmux session running
[18:28] <marcoceppi> At least until that functionality is merged into the _mup_ bot
[18:29] <jrgifford> i'm going to ctrl-c it at the console, it'll be (hopefully) right back
[18:29] <jrgifford> do you really want it in #juju-dev ?
[18:31] <marcoceppi> Juju questions should end up in this room, not juju-dev
[18:31] <jrgifford> ok
[18:31] <jrgifford> i think i fixed it
[18:31] <jrgifford> lets try it in a moment
[18:32] <jrgifford> Bug #1002406
[18:32] <_mup_> Bug #1002406: Add policy to discuss when charmers members should be automatically removed <policy> <Juju Charms Collection:New> < https://launchpad.net/bugs/1002406 >
[18:32] <marcoceppi> cool
[18:32] <jrgifford> looks like i fixed that
[18:32] <marcoceppi> jrgifford: is the source for this public?
[18:32] <jrgifford> marcoceppi: um, no. at least, not right now as far as i know
[18:33] <jrgifford> i think amithkk's going to submit a merge request like, next week or something with his changes
[18:35] <SpamapS> jrgifford: *thank you*
[18:36] <jrgifford> SpamapS: no problem.
[18:36] <jrgifford> it's on my server, i'd be really disappointed if i couldn't stop it. :P
[19:04] <marcoceppi> negronjl SpamapS jcastro with the "Review Queue" stuff merged in to charm-tools do we still want to pursue that web-based thing?
[19:05] <SpamapS> marcoceppi: I'm fine w/ the cmdline tool. :)
[19:06] <marcoceppi> Guess I'll learn Django another day
[19:06] <marcoceppi> :)
[19:37] <jcastro> yes
[19:37] <jcastro> let's keep it web based
[19:37] <jcastro> I mean, having a companion CLI tool is nice
[19:37] <jcastro> but it'd be nice to have it part of the web UI, so anyone can see what's going on, etc.
[19:39] <marcoceppi> Django is back on, hazmat if I get you code for this in the form of a Django project will you be able to integrate it into the current Charm World thing?
[19:57] <hazmat> marcoceppi, negronjl already provided it
[19:57] <marcoceppi> oh
[19:57] <marcoceppi> makes that easy
[20:42] <SpamapS> :)
[21:17] <hazmat> negronjl, http://jujucharms.com/review-queue
[21:19] <marcoceppi> hazmat: sexy
[21:20] <marcoceppi> Should we drop the Charm Needed: stuff?
[21:20] <hazmat> marcoceppi, yeah.. probably, the need has been fufilled
[21:21] <hazmat> although that's a matter of perspective i suppose
[21:21] <hazmat> its still needed till its in 'main'
[21:21] <marcoceppi> IMO, if it's a bug in the charm project, it's for a charm being worked on; Since we can open bugs directly against promulgated charms, etc
[21:27] <SpamapS> I'd leave the Charm needed
[21:27] <SpamapS> For the Proposals I'd rather see the URL there than "Proposal"
[21:27] <SpamapS> Though I think we talked about grabbing the summary of any linked bugs
[21:29] <hazmat> SpamapS, fixing that right now
[21:29] <hazmat> a couple of other minors as well
[21:29] <SpamapS> Another way to go would be Proposal: $(charmname)
[21:30] <hazmat> SpamapS, i'm doing Merge proposal for %{charmname/branch_name}
[21:31] <hazmat> hm.. although perhaps i should just do %series/charm_name
[21:31] <hazmat> yeah.
[21:32] <SpamapS> Yeah perfect
[21:47] <hazmat> SpamapS, should be good now
[21:47] <hazmat> let me know if you think of any other tweaks
[21:48] <SpamapS> hazmat: its sorted with newest on top
[21:48] <hazmat> SpamapS, you want inverse?
[21:48] <hazmat> er. normal sort
[21:48] <SpamapS> well I think we do
[21:48] <hazmat> fifo
[21:48]  * SpamapS is once again spinning too many plates to recall which direction this plate should be spinning
[21:48] <hazmat> cool
[21:50] <hazmat> SpamapS, fixed.. you'll have to ctrl-r for your browser to force a fetch
[21:50] <SpamapS> hazmat: looks good
[21:50] <hazmat> its setup for a 3m http cache, and a 10m cron update
[21:51] <SpamapS> I think we may want to remove In Progress tho
[21:51] <SpamapS> hazmat: thats mighty fine. :)
[21:51] <hazmat> SpamapS, most of those have branches attached re 'in progress'
[21:51] <hazmat> your call though
[21:54] <hazmat> SpamapS, for example.. https://bugs.launchpad.net/charms/+bug/983339  this one wouldn't be in the queue otherwise
[21:54] <_mup_> Bug #983339: New Charm: munin-node <new-charm> <Juju Charms Collection:In Progress> < https://launchpad.net/bugs/983339 >
[21:54] <hazmat> well i guess it would for being a new charm tag
[21:55] <SpamapS> hazmat: the merge proposals In Progress are fine. The bugs, are not.
[21:55] <SpamapS> a bug in progress means charmers is not expected to do anything
[21:56] <SpamapS> though perhaps instead, we should just unsubscribe charmers and let the user ask for attention again when its time.
[21:56] <hazmat> SpamapS, so the munin charm isn't ready for review?
[21:56] <SpamapS> hazmat: the munin merge proposal is
[21:56] <SpamapS> err
[21:56] <hazmat> SpamapS, :-)
[21:56] <SpamapS> no never mind
[21:57] <SpamapS> hazmat: so james page set it back to 'In Progress' to suggest that its not ready for any further review. I think.
[21:58] <hazmat> SpamapS, work in progress works well on a merge proposal.. on a bug there isn't a clear way to indicate ready for review outside of a tag
[21:58] <hazmat> right now pretty much all bug states outside of committed, released with a 'new-charm' tag are considered part of the queue
[22:00] <SpamapS> hazmat: yeah, I think we just need to think about how we want to manage the queue a bit
[22:00] <SpamapS> hazmat: simplest is to just have new-charm be the clear "I need help" flag
[22:00] <SpamapS> or, I think we'll change it to subscribing ~charmers
[22:01] <hazmat> SpamapS, new-charm works for the initial point of contact, but as things progress, its unclear that it remains cogent of the current state of the charm branch
[22:01] <hazmat> SpamapS, looking over https://bugs.launchpad.net/charms/+bug/806044 for example, the author has incorporate review feedback, but there's really no way of knowing it from the bug per se.
[22:01] <_mup_> Bug #806044: Charm needed: Moodle <new-charm> <Juju Charms Collection:In Progress by rkather> < https://launchpad.net/bugs/806044 >
[22:19] <dpb_> hi folks.  I had a 75GB log file after just a few days of running a local lxc 2-service test bed.  Is this a known issue?  (machine-agent.log)
[22:35] <hazmat> dpb_, yes.. its fixed, and awaiting an sru
[22:35] <hazmat> SpamapS, any updates on that getting pushed out?
[22:40] <dpb_> hazmat: cool, thx
[22:40] <dpb_> hazmat: in the ppa already?
[23:11] <SpamapS> hazmat: I'll upload to precise-proposed tomorrow
[23:44] <SpamapS> wow.. charm getall takes a *long* time