[12:20] <ubotu> New bug: #125147 in malone "ipw2200 intel wireless driver not the latest" [Undecided,New]  https://launchpad.net/bugs/125147
[12:55] <ubotu> New bug: #125155 in launchpad-bazaar "code-import-sync script should delete dummy import branches" [Undecided,New]  https://launchpad.net/bugs/125155
[01:24] <kiko> Fujitsu, have you ever developed using SQLObject?
[01:24] <kiko> there are so many problems I don't know where to start from :-)
[01:24] <kiko> but really, the two things that storm gives you on top of a better design:
[01:25] <kiko> - support for connecting to multiple databases at once
[01:25] <kiko> - an extensible API that lets you fetch objects and groups of objects in a single database query
[01:25] <kiko> (i.e. aggregate functions side-by-side with instances)
[01:26] <Fujitsu> I have developed small things with it, but nothing biggish.
[01:26] <kiko> it's generally okay
[01:26] <kiko> but the code is not very nice
[01:26] <radix> By the way, we've got a #storm channel on Freenode now. It's already kicking with activity.
[01:26] <Fujitsu> I suppose you wouldn't be reinventing the wheel without good reason.
[01:26] <kiko> and the API limitations above are a showstopper if you want to connect to multiple DBs
[01:26] <Fujitsu> Ah, nice.
[01:27] <kiko> or if you are performance-constrained
[01:27] <Fujitsu> Anyway, good to see small bits of LP being opened :)
[01:27] <kiko> we're getting there
[05:00] <mpt> Gooooooooooooooooood afternoon Launchpadders!
[05:03] <Fujitsu> Hi mpt.
[05:30] <ubotu> New bug: #125173 in malone "+viewstatus should no longer exist" [Undecided,New]  https://launchpad.net/bugs/125173
[07:50] <gavinbaker> not to be a jerk, but is there a problem with launchpad.net's servers atm?
 is lp really slow today?
 afc was complaining about timeouts before
 now opening a bug page is taking 20s
[07:50] <poolie> in fact it's now up to nearly a minute
[07:51] <poolie> i think something must be wrong, because i would normally at least get an error message 
[07:51] <gavinbaker> i'm getting 100% packet loss, and confirmed by another user.
[07:58] <jml> spiv: can I grab you for a pre-impl call?
[08:00] <spiv> jml: sure
[08:02] <poolie> gavinbaker, our sysadmins are working on the problem
[08:02] <gavinbaker> poolie, thanks for the status update
[08:02] <jml> spiv: on skype?
[08:03] <gavinbaker> and we were just looking forward to closing some bugs, too :)
[08:03] <poolie> :)
[08:18] <mwh> no power in the DC again?
[08:18] <poolie> something like that
[08:18] <paulproteus> If someone gives me the Launchpad source, I could set up a live mirror service on my network space.
[08:19] <gavinbaker> paulproteus, sneaky way of getting the source ;)
[08:19] <paulproteus> I know it requires a few machines, but it happens that I do have a few machines.
[08:19] <mwh> i think getting you the database would take a while...
[08:20] <paulproteus> mwh, Especially if the Ethernet switches aren't powered on. (-;
[08:41] <poolie> it's back now 
[08:43] <gavinbaker> ah, so it is. thanks poolie 
[09:21] <carlos> morning
[09:24] <jtv> morning
[09:32] <cprov> good morning
[10:40] <pcardune> Word on the street at EuroPython is that the bzr smart server is now available on LaunchPad as of last thursday?  Is this true? and where do I find out how to use it?
[10:41] <poolie> pcardune, i think that's true
[10:44] <poolie> pcardune, you should be able to use it by just changing the sftp to bzr+ssh at the start of your urls
[10:44] <poolie> this may only work for branches that you can write to though?
[10:45] <mwh> no, there's read only access to all branches
[10:49] <poolie> mwh, bzr: ERROR: Not a branch: bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk/
[10:49] <poolie> oh i see
[10:49] <poolie> there's no access to mirrored branches?
[10:50] <mwh> that shouldn't make any difference
[10:50] <poolie> well, it works with http and fails with ssh and sftp
[10:52] <mwh> it's working for me
[10:55] <poolie> really
[10:56] <mwh> slowly, because i'm on a choked connection but yes
[10:56] <poolie> you can access that branch i mentioned? bzr.dev?
[10:58] <mwh> yes
[11:02] <mwh> mithril:~/quake/qdp mwh$ bzr info bzr+ssh://mwhudson@bazaar.launchpad.net/~bzr/bzr/trunk/
[11:02] <mwh> Location:
[11:02] <mwh>   branch root: bzr+ssh://mwhudson@bazaar.launchpad.net/~bzr/bzr/trunk/
[11:02] <mwh> etc
[11:04] <poolie> that fails for me
[11:04] <poolie> even if i take out the mwhudson :)
[11:04] <mwhudson> bizarre
[11:05] <mwhudson> that's with 0.15 i think
[11:05] <poolie> i doubt it's a client side thing
[11:05] <poolie> i can see the server saying it doesn't exist 
[11:05] <poolie> with spiv's nice trace feature
[11:13] <mwh> how very strange
[11:15] <mwh> (it is, good)
[11:18] <mwh> the logs from the supermirror are not exactly informative :/
[12:17] <Lux01> hi. I'm new to Launchpad and I'm having difficulty registering a bzr branch. I don't understand what format it wants the "Branch URL" to be. I looked at www.bazaar-vcs.org but couldn't find anything of help.
[01:50] <ubotu> New bug: #125232 in launchpad "FAQ about "Launchpad is down for maintenance" is out of date" [Undecided,New]  https://launchpad.net/bugs/125232
[03:43] <kiko> cprov, bigjools: ping
[03:44] <bigjools> kiko, yep?
[03:44] <kiko> bigjools, can you two step into #lm for one sec?
[04:00] <flacoste> it's time for the non .au Launchpad Reviewers Meeting
[04:00] <flacoste> who's here today?
[04:00] <statik> me
[04:00] <barry> me
[04:01] <flacoste> BjornT send his apology, he's at EuroPython
[04:01] <barry> bac said he'd be right back, so maybe it's just the 4 of us
[04:01] <flacoste> Salgado is somewhere in Scotland
[04:01] <bac> me
[04:02] <flacoste> == Agenda ==
[04:02] <flacoste>  * Roll call
[04:02] <flacoste>  * Next meeting
[04:02] <flacoste>  * Queue status.
[04:02] <flacoste>  * Timely assignment of queue items
[04:02] <flacoste> Is July 19th 16:00 UTC a good time for next meeting?
[04:02] <flacoste> err, sorry
[04:02] <flacoste> July _18th_
[04:03] <barry> you mean instead of 1400 utc?
[04:03] <bac> +1 1400 UTC
[04:03] <flacoste> yeah, 1400 UTC
[04:03] <flacoste> sorry
[04:03] <barry> +1
[04:03] <statik> +1
[04:04] <flacoste> queue status: i see a big improvement on the queue from last Friday
[04:04] <flacoste> but the queue is still huge
[04:05] <barry> indeed
[04:05] <flacoste> 35 open reviews, 28 over SLA
[04:05] <bac> huge *and* colorful
[04:05] <flacoste> what's worrying me is that we also have a lot of unallocated reviews
[04:05] <flacoste> 16 unallocated
[04:06] <statik> lifeless said that he would not be allocating reviews while he was away, did someone else take over?
[04:06] <barry> what worries me is that reviewers also have a limited amount of time to resolve the review comments of their own branches too.  there's a real tension there that could end up biting us.
[04:06] <flacoste> indeed
[04:07] <flacoste> statik: i heard james took the responsibility
[04:07] <flacoste> but i never saw that on-list
[04:07] <statik> flacoste: oh, good to know. right, I never saw an ack on-list
[04:07] <flacoste> and i'm sure it wasn't true, otherwise james forgot to do it
[04:07] <barry> flacoste: i remember the same thing.  also, we're allowed to snag items off the general queue if we have some free time.  i plan on doing that.
[04:07] <lifeless> jamesh agreed to do it on irc
[04:08] <bac> i'll try to take a couple later this afternoon.
[04:08] <flacoste> he did
[04:08] <flacoste> ?
[04:08] <lifeless> yes
[04:08] <flacoste> then he forgot to do it...
[04:08] <flacoste> barry: i'll clear my queue today and continue to snag off items afterwards
[04:09] <barry> i propose to keep things fair, snag branches from the top, unless of course it's your branch
[04:09] <flacoste> barry: right
[04:10] <flacoste> off topic: i'm pleased though with the new incremental diff support
[04:11] <flacoste> should make allocation easier also
[04:11] <flacoste> since you'll see the right size of the diff!
[04:11] <barry> it really helped for one of the reviews i did!
[04:11] <lifeless> yes
[04:11] <flacoste> statik, bac: what's your availability for reviews this week?
[04:12] <bac> i'm tied up most of the day. can do some tomorrow.  i have an unallocated branch in the queue that will take priority when it gets reviewed.
[04:12] <statik> flacoste: I have one overdue review, and have a lot of other commitments...I was actually considering rejecting the current review, but I feel too guilty to do that
[04:13] <statik> I got partway through it yesterday
[04:14] <flacoste> ok, anything else to add on queue status?
[04:14] <flacoste> 3
[04:14] <flacoste> 2
[04:14] <bac> yes
[04:14] <flacoste> ?
[04:14] <bac> i have a review for barry that needs to be mentored
[04:14] <flacoste> bac: send it my way
[04:14] <bac> kiko tentatively accepted it yesterday but i may need to come back today 
[04:14] <bac> thanks flacoste 
[04:14] <flacoste> anything else?
[04:15] <flacoste> moving on: Timely assignment of queue items
[04:15] <flacoste> i think this is a follow-up from last week
[04:16] <flacoste> do we have something else to say about this?
[04:17] <barry> i don't ;)
[04:17] <flacoste> i have a question:
[04:17] <flacoste> anybody noticed that allocation wasn't taking place?
[04:17] <flacoste> i did
[04:18] <flacoste> my question is what should we do, when we notice this?
[04:18] <bac> yes
[04:19] <flacoste> i think prompt response to this event is needed, since the review process becomes an important plan of having a smooth time-based release
[04:19] <barry> flacoste: several thoughts...
[04:20] <barry> we should explicitly state who the allocator is on the PendingReviews page, and if that person is away, be explicit about handing it off to someone else (i.e. update the page)
[04:20] <barry> so at least we're certain who to bug when we notice the constipation
[04:20] <barry> second...
[04:20] <barry> perhaps we need a cronjob or something that emails the reviews list when it sees no allocations from the general queue in a day or two, or just send that email to the allocator
[04:21] <barry> it could probably be done as part of the pending-reviews script
[04:21] <barry> (over)
[04:22] <bac> what about spreading out the responsibility?  perhaps having a non-AU person help with allocations.
[04:22] <flacoste> lifeless: any comments on this ^^^
[04:22] <barry> bac: oh that's so low-tech it just might work :)
[04:22] <flacoste> barry: i think we definitavely need #1
[04:23] <flacoste> i had a similar idea to your second suggestion, but low-tech
[04:23] <lifeless> salgado is doing offset allocations too, but hes on leave right now
[04:23] <lifeless> I agree that we should record who is nominated when allocations change hands temporarily
[04:23] <flacoste> reviewers noticing a lapse in allocation should mail the person responsible cc launchpad-reviews
[04:23] <barry> flacoste: +1
[04:23] <lifeless> if you notice constipation, why not just allocate ?
[04:24] <flacoste> that's another possibility
[04:24] <lifeless> I'm -1 on whinging, just dig in an fix it
[04:24] <lifeless> send a mail saying that you ahve done an adhoc allocation sure.
[04:24] <flacoste> i like this proposal
[04:24] <flacoste> any objections?
[04:24] <lifeless> but whatever reason the person allocating hasn't won't be fixed by just amiling - thus the do it and mail combination.
[04:25] <barry> well, i just want to be careful not to perceive constipation when it's not there
[04:25] <lifeless> ideally everything would be allocated always
[04:25] <lifeless> there are some concerns 
[04:25] <flacoste> lifeless: yeah, maybe you could explain how you do the allocation?
[04:26] <barry> +1, on a wiki page linked from PendingReviews preferrably
[04:26] <flacoste> obvious criteria is previous allocation of reviewer
[04:28] <barry> we also have new reviewer nominations coming up soon, so we should think about that.  more reviewers would definitely help
[04:29] <flacoste> indeed
[04:29] <barry> (and graduations of currently mentored reviewers :)
[04:29] <lifeless> problem is that if say spiv does his reviews at 9am
[04:30] <lifeless> if I allocate at 9am, then I can see his load at the same point in his cycle each day
[04:31] <lifeless> if I say 'hes busy, no new reviews', he does his reviews, and then someone comes along at 11am and says 'look spiv has space' this may cause uneven load
[04:31] <lifeless> load is really the number of needs-review PLUS the number of needs-reply I think, but needs-reply could maybe be weighted lower or something
[04:32] <lifeless> thats my only concern about any reviewer allocating as needed. But I think its better to allocate when it is congested to keep it moving.
[04:32] <flacoste> to alleviate the "point-in-time" problem we could track the number of lines reviewed in the last week
[04:33] <flacoste> this would give a better idea of the workload that is more independant than the time where people do reviews
[04:34] <barry> flacoste: something like that might work.  it should take into account merge-approved and merge-conditional for the week too, weighted down though.  maybe something like lines(needs-review) + lines(merge-*, needs-reply) * 0.5 ?
[04:34] <lifeless> I think its good to address that in reviews-in-lp
[04:34] <lifeless> but not enough of a win to do today
[04:34] <lifeless> congestion should be the exception no tthe rule
[04:35] <flacoste> right
[04:35] <flacoste> it usually work fine
[04:35] <lifeless> I'd add a heuristic to 'its congested' - 10 unassigned is not congested.11 is
[04:35] <lifeless> its not uncommon for me to get up and see 10 having turned up overnight/over the weekend
[04:35] <lifeless> and we have enough reviewers that thats only a couple each
[04:36] <barry> sounds good
[04:36] <flacoste> to me congested is more two days without allocation
[04:36] <flacoste> regardless of number of unallocated
[04:36] <lifeless> flacoste: trust me, we can congest instantly at release time :)
[04:37] <flacoste> i think this is a different problem
[04:37] <lifeless> indeed :)
[04:37] <lifeless> anyhow, the huesristic is just to put a feel on it, really use yoru common sense
[04:37] <flacoste> the prob lem I'm concerned is that when allocation doesn't happen for two days, the newly allocated review is right over the SLA
[04:37] <lifeless> meh, my spellink iz bustificated
[04:37] <flacoste> use common sense: +1 on that
[04:37] <flacoste> ok, any other comments on this topic?
[04:38] <flacoste> 3
[04:38] <flacoste> 2
[04:38] <flacoste> 1
 I object!  </whisper>
[04:38] <Hobbsee> :p
[04:38] <lifeless> troll!
[04:38] <barry> Hobbsee: can we start assigning reviews to you? :)
[04:38] <flacoste> any other things to discuss?
[04:38] <flacoste> 3
[04:38] <Hobbsee> barry: hah
[04:39] <flacoste> 2
[04:39] <flacoste> 1
[04:39] <flacoste> MEETING ENDS
[04:39] <barry> thanks!
[04:39] <flacoste> Thanks everyone for attending
[04:39] <bac> thanks all
[04:39] <Hobbsee> barry: now i'd find that a little difficult, seeing as i couldnt access the stuff to review :P
[04:39] <barry> Hobbsee: details, details :)
[04:40] <Hobbsee> barry: haha.  nor how to review, etc, etc :P.  but mere details, yes.
[04:40] <barry> :)
[05:06] <ubotu> New bug: #125261 in blueprint "Partially functioning blueprint registration page for distro series." [Undecided,New]  https://launchpad.net/bugs/125261
[06:50] <ubotu> New bug: #125279 in launchpad "Publishing an update to *-proposed incorrectly marks bug "Fix Released"" [Undecided,New]  https://launchpad.net/bugs/125279
[09:07] <tsmithe> having never been an archive admin before, i'd like to learn how to remove packages from one; i'm mainly interested in removing packages from my PPA
[09:09] <kiko> tsmithe, you can't do that yes. RSN. :)
[09:09] <kiko> yet.
[09:10] <tsmithe> RSN?
[09:10] <tsmithe> i guess i'll just have to bump a new version upload
[09:11] <tsmithe> (just seems so cluttered after making one versioning mistake :) )
[09:16] <statik> I know, right? As soon as I uploaded something to my PPA I felt the need to delete it.
[09:17] <tsmithe> hehe
[09:18] <statik> there is some part of my brain incapable of seeing my mistakes until I expose them publicly
[09:18] <tsmithe> well, i often find that. (although this time it wasn't a mistake, just ignorance)
[09:23] <kiko> tsmithe!
[09:23] <kiko> Real
[09:23] <kiko> Soon
[09:23] <kiko> Now
[09:23] <kiko> :)
[09:23] <tsmithe> ahhhha
[09:23] <tsmithe> (duh! :p)
[09:25] <tsmithe> how will canonical handle copyright issues in PPAs? what about people distributing "bad" code?
[09:27] <kiko> tsmithe, with a Big Stick :)
[09:27] <kiko> more seriously
[09:27] <tsmithe> hehe
[09:27] <kiko> when requesting a PPA you'll be asked to accept the TOU
[09:28] <kiko> and we will send chinese ninjas to your home if you violate them
[09:28] <tsmithe> makes sense
[09:28] <kiko> err, sorry, typo
[09:28] <tsmithe> haha
[09:28] <kiko> I meant we will be very cross if you violate them
[09:28] <tsmithe> yes, obviously
[09:28] <tsmithe> (i don't recall accepting any TOU :p)
[09:28] <kiko> tsmithe, you're special!
[09:28] <tsmithe> yay!
[09:29] <kiko> dogfoodin' the evil code
[09:29] <tsmithe> hehe
[09:55] <LarstiQ> kiko: http://timhatch.com/projects/pybraces/
[10:03] <kiko> LarstiQ, stop trying to scare me I'm sensitive
[10:03] <LarstiQ> kiko: but you mentioned evil!
[10:05] <kiko> in the PPA context
[10:05] <kiko> OMG is that going to be in a PPA too!!!
[10:47] <tsmithe> rargh i want to delete all these packages and start again :'(
[10:48] <kiko> tsmithe, :) just keep uploading and the domination code will get rid of the old ones.
[10:49] <tsmithe> well, i don't want to break upgrades between repositories, and i just realised, by bumping a version to fix the ftbfs, i already did
[10:50] <kiko> between repositories?
[10:50] <kiko> by bumping version do you mean tacking on -tsmithe2 or something different?
[10:50] <tsmithe> kiko, that kind of thing :)
[10:51] <kiko> that shouldn't break upgrades
[10:51] <tsmithe> by between repositories, i mean this is a preliminary package, which i hope to get uploaded to debian
[10:51] <tsmithe> hmm ok if you say so