[12:30] <ubotu> New bug: #116309 in soyuz "LP: #nnnn should be linked to the bug report." [Undecided,Unconfirmed]  https://launchpad.net/bugs/116309
[01:48] <owh> I have a bug that has a fix released and have now been asked to provide a backport to Dapper. How do I tell launchpad? Am I supposed to lodge a new bug and link the two?
[01:50] <owh> The answer to my question is: "Click on Nominate for release" - cheers.
[02:18] <keescook> any idea why I can't approve/deny the requested nominations for bug 62831 ?
[02:18] <ubotu> Launchpad bug 62831 in dosfstools "fsck.vfat truncates files of 4294967295 bytes length to 0 bytes at boot-time" [High,Fix released]  https://launchpad.net/bugs/62831 - Assigned to StefanPotyra (sistpoty)
[02:18] <Hobbsee> boo
[02:19] <keescook> eek
[02:21] <Hobbsee> hehe :)
[02:23] <Hobbsee> haha
[02:24] <Hobbsee> that really was fun :)
[02:24] <Hobbsee> watching everyone draw cards, as they had NFI what was going on, and thought that was the least-penalty-option
[02:24] <jml> I've heard too much about this Mao game
[02:24] <jml> I should play it one day
[02:24] <jml> Hobbsee: but I fear that you've just given an important clue away :)
[02:24] <Hobbsee> jml: yes you should.  at a UDS.
[02:25] <Hobbsee> jml: nah.  that was one of my rules, not a base rule.
[02:25] <jml> Hobbsee: ah :)
[02:28] <keescook> I really enjoyed "this is not the 6 of diamonds"  ...  "lying *card*"
[02:31] <Hobbsee> haha, yeah, that was great :D
[02:31] <Hobbsee> keescook: did you impose that rule?
[02:32] <keescook> Hobbsee: no no, I'm still a Mao newb.  I think that was mdz, but I may be misremembering.
[02:32] <Hobbsee> "failure to say "this is not the 6 of diamons"...*card*..."continued failure to say "this is not the 6 of diamons"...*card*...."this is not the six of diamonds"...'lying"...*card*
[02:32] <Hobbsee> yep
[02:32] <keescook> hehe
[02:32] <Hobbsee> he was the sphere/cube one
[02:34] <Hobbsee> keescook: i thought you'd learned now - hte newb's make the most evil rules
[02:35] <keescook> :)
[03:15] <Hobbsee> SteveA: ping?
[03:21] <kiko> Hobbsee, he's way asleep
[03:21] <kiko> how are you, though?
[03:24] <Hobbsee> kiko: i'm good :)
[03:24] <Hobbsee> kiko: been snowed under with assignments, etc
[03:24] <Hobbsee> unfortunately
[03:24] <Hobbsee> kiko: how'd the bug stuff for LP go?
[03:24] <ajmitch> hello kiko 
[03:24] <kiko> Hobbsee, went very well
[03:24] <kiko> I had a good time
[03:25] <kiko> and BjornT and I am going to have fun this cycle!
[03:25] <kiko> hey ajmitch 
[03:25] <Hobbsee> :)
[03:25] <kiko> how is it going down under?
[03:25] <Hobbsee> it was cool meeting up with all of you
[03:25] <kiko> yeah pity I was so busy and sick
[03:25] <Hobbsee> kiko: the shoestring internet is crap, and it's cold
[03:25] <kiko> I hate being sick
[03:25] <kiko> the internet here is worse than yours
[03:25] <kiko> it's cold today too
[03:25] <Hobbsee> heh.  it took me a couple of days, and someone to point you out, to realise who you were :P
[03:25] <ajmitch> impossible
[03:25] <kiko> I rode 3h in the rain
[03:25] <kiko> it's not impossible
[03:25] <kiko> voip doesn't work
[03:25] <kiko> etc
[03:26] <ajmitch> Hobbsee: shocking, how could you not know kiko?
[03:26] <Hobbsee> ajmitch: hadnt seen a picture of him?
[06:17] <Hobbsee> kiko: ping
[06:17] <Hobbsee> kiko: we need a launchpad bug hall of shame, please.
[06:18] <Hobbsee> https://bugs.launchpad.net/ubuntu/+bug/116344 is a good candidate.
[06:18] <ubotu> Launchpad bug 116344 in Ubuntu "Sifilinaptic Package Error for 3 days" [Undecided,Unconfirmed]  
[06:21] <mpt> that's weird
[06:21] <mpt> for me that page is completely empty
[06:21] <mpt> except for the header and the footer
[06:22] <thumper> mpt: I see it
[06:22] <Hobbsee> mpt: so launchpad has decided to hate you today?  it has been tempramental this week
[06:22] <thumper> Hobbsee: I like your comment
[06:22] <mpt> It reappeared on reload
[06:22] <Hobbsee> thumper: *grin*
[06:22] <mpt> I wonder if "Usuchtu" is a misspelling of "Usucktu"
[06:22] <Hobbsee> i suspect so
[06:22] <Hobbsee> i suspect the account should be closed...
[06:23] <Hobbsee> but cant think of a legit reason for it, and preemptive striking isnt a great idea
[06:23] <Hobbsee> AND THIS IS WHY WE NEED HARDER TO FILE BUGS.
[06:23] <mpt> Hobbsee, you know what *really* annoys people who are being rude?
[06:23] <mpt> Being extremely polite and friendly to them.
[06:23] <ajmitch> politeness?
[06:23] <Hobbsee> mpt: this is true.
[06:24] <mpt> And the plus side is
[06:24] <mpt> every so often, they'll feel ashamed, and they'll flip.
[06:24] <mpt> Not often, but occasionally.
[06:25] <mpt> (Disclaimer: Taking advice from mpt on politeness is like {insert zany metaphor here}.)
[06:25] <Hobbsee> mpt: heh, true.
[06:26] <mpt> but to be serious just for a minute
[06:26] <mpt> Why on earth is synaptic saying "_cache->open() failed, please report" when it knows very well that it's not the sort of error that should be reported?
[06:26] <mpt> That *is* a bug.
[06:27] <Hobbsee> it's also already reported, iirc.  or similar to that
[06:27] <Hobbsee> not because of the sources list being botched, though
[06:27] <jamesh> mpt: being helpful in this case would be a breach of privacy
[06:27] <jamesh> do you really want people to know that _cache->open() failed for you without your consent?
[06:28] <mpt> w.r.t. "harder to file bugs", I have previously proposed a slider for project maintainers on how difficult it should be to report bugs on the project
[06:28] <mpt> Easier to report bugs ==O[06:28] <jamesh> ranging from "let any spam through" to GNITS?
[06:28] <Hobbsee> mpt: there were discussions about this at UDS, i'm not sure hwo much of it you heard
[06:28] <Hobbsee> GNITS?
[06:28] <mpt> Hobbsee, I wasn't there at all
[06:29] <Hobbsee> mpt: which is why i pinged kiko
[06:29] <Hobbsee> knowing that he'd get the reference
[06:29] <jamesh> oops.
[06:29] <jamesh> GNATS is what I meant
[06:29] <jamesh> http://www.gnu.org/software/gnats/
[06:29] <jml> I think the highest level is "There is a rare blue flower that grows only on the peak of Death Mountain, pluck the flower, mail it to the maintainer, then file your bug"
[06:30] <Hobbsee> mpt: basically about making them include package versions, maybe using the answer tracker, then being able to hit a button saying "this is a bug" if someone privelaged came along, etc
[06:30] <mpt> and on that note
[06:30] <mpt> Goooooooooooooooooooood afternoon Launchpadders!
[06:30] <ajmitch> hello mpt!
[06:30] <ajmitch> :)
[06:30] <mpt> hello hello
[06:31] <jamesh> here's a GNATS installation: http://gnats.wookimus.net/cgi-bin/gnatsweb.pl?database=gnats
[06:32] <Hobbsee> mpt: https://bugs.launchpad.net/ubuntu/+bug/111688 is similar
[06:32] <ubotu> Launchpad bug 111688 in Ubuntu "E: Problem with MergeList /var/lib/apt/lists" [Undecided,Unconfirmed]  
[06:33] <ajmitch> Hobbsee: so the real bug is the error message that it gives to the user
[06:33] <Hobbsee> yes
[06:33] <Hobbsee> https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/112195 is good, too
[06:33] <ubotu> Launchpad bug 112195 in synaptic "synaptic broken" [Undecided,Unconfirmed]  
[06:34] <Hobbsee> seeing as synaptic is dying over an unofficial deb
[06:34] <mpt> jamesh, it times out for me. I guess the "how difficult to report a bug" knob is turned up to 11 today.
[06:34] <ajmitch> Hobbsee: quite right, synaptic shouldn't die like that
[06:35] <Hobbsee> ajmitch: sounds good ot me.  or at least a "if you want to install random debs, you cant use synaptic for them"
[06:35] <ajmitch> that's silly
[06:36] <Hobbsee> well, yeah
[08:18] <carlos> morning
[08:19] <beuno> carlos: morning  :D
[08:20] <beuno> carlos: I'd like to talk to you about a spec I had scheduled for Sevilla UDS which didn't get any love whenever you have time
[08:20] <carlos> beuno: ok
[08:21] <carlos> beuno: URL?
[08:21] <beuno> carlos: https://blueprints.launchpad.net/rosetta/+spec/rosetta-stats-enhancement
[08:24] <carlos> beuno: I don't see any problem that prevent us to implement it
[08:24] <beuno> carlos: would be *extremely* helpful  :D
[08:24] <carlos> beuno: mrevell uses something like that for the whole site report so implementing it would be also helpful for him
[08:25] <carlos> I will see when could we schedule it
[08:25] <beuno> carlos: that would be great, thanks!
[08:26] <carlos> beuno: thanks for the spec!
[08:26] <beuno> carlos: don't provoke me, I might end up doing them regularly     :p
[08:30] <carlos> beuno: and you will be welcome ;-)
[08:31] <beuno> carlos,  :D
[10:55] <ubotu> New bug: #116364 in malone "Better handling of the "this is my bug" +filebug case" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116364
[11:02] <dholbach> hiya
[11:02] <dholbach> what can I do about      "bzr: ERROR: Lock was broken while still open: LockDir(sftp://jonathan@bazaar.launchpad.net/%7Emotu-mentoring-reception/reception-data/main/.bzr/branch/lock) - check storage consistency!"   ?
[11:04] <dholbach> (neither jonathan or I can push to the branch anymore)
[11:07] <carlos> dholbach: hmmm, I think you should check on #bzr
[11:07] <carlos> from that, I understand that one of your bzr commands didn't pay attention to the lock...
[11:07] <carlos> and it smells like a bug ...
[11:07] <dholbach> yes
[11:08] <dholbach> but something in LP is broken now and we can't use the branch :)
[11:09] <carlos> dholbach: well, I don't think it would be too different from any other bzr hosting service so maybe there is a way to fix it in your side so checking with #bzr guys doesn't hurt
[11:09] <carlos> while you wait for ddaa, spiv, jamesh or any other developer that knows a bit more about bzr :-)
[11:10] <dholbach> bzr push --overwrite   from a 'clean branch' doesn't work either - so I don't know how to fix it on my side
[11:10] <Hobbsee> hi ddaa 
[11:11] <ddaa> broken lock...
[11:11] <Hobbsee> you're spied!
[11:11] <ddaa> and "bzr break-lock" does not fix it, right?
[11:11] <carlos> ddaa: the error seems to say that there would be data corruption... or that's what I understand
[11:11] <carlos> not just an stalled lock
[11:11] <ddaa> there _might_ be
[11:11] <ddaa> chances are there is not
[11:12] <carlos> indeed
[11:12] <ddaa> still better to run bzr check if you can
[11:12] <ddaa> so, what's the question?
[11:12] <dholbach> highvoltage: can you run     bzr check        on your local branch?
[11:12] <ddaa> that's funny how this message paralyses people...
[11:13] <ddaa> when they should just run "bzr check" and go on with life...
[11:13] <dholbach> ddaa: highvoltage Ctrl-Ced a commit to a LP branch, now we both get "bzr: ERROR: Lock was broken while still open: LockDir(sftp://LPID@bazaar.launchpad.net/%7Emotu-mentoring-reception/reception-data/main/.bzr/branch/lock) - check storage consistency!" when we try to push to that branch - even using --overwrite does not help
[11:13] <ddaa> dholbach: does "bzr break-lock" help?
[11:13] <dholbach> no
[11:13] <ddaa> --overwrite does not really overwrite the branch, complain to #bzr about the wording
[11:14] <dholbach> I guess that highvoltage has to use it on his local branch and commit/push that
[11:14] <highvoltage> bzr check says:
[11:14] <highvoltage> checked branch file:///home/jonathan/main/ format Bazaar-NG branch format 5
[11:14] <highvoltage> checked repository <bzrlib.transport.local.LocalTransport url=file:///home/jonathan/main/> format <RepositoryFormatKnit1> 4 revisions 4 unique file texts 0 repeated file texts 1 weaves
[11:14] <ddaa> highvoltage: does it scream murder?
[11:15] <ddaa> dholbach: we have a bug in sftp rename semantics that fucks up the locking protocol in some cases.
[11:15] <ddaa> actively being worked on by jml
[11:15] <dholbach> ah ok
[11:16] <dholbach> bzr break-lock sftp://LPID@bazaar.launchpad.net/%7Emotu-mentoring-reception/reception-data/main/.bzr/branch/lock       worked
[11:16] <dholbach> highvoltage: can you use    bzr pull    now?
[11:16] <highvoltage> dholbach: yes, that part seems to work fine
[11:16] <dholbach> thanks ddaa, I didn't know I had to give it the complete URL to the lock file
[11:16] <ddaa> hu
[11:16] <ddaa> you're not supposed to
[11:16] <jml> well, not _right_ now
[11:17] <dholbach> that's what made it work
[11:17] <jml> but tomorrow morning definitely :)
[11:17] <ddaa> oh well
[11:17] <dholbach> neat-o
[11:17] <dholbach> thanks a lot guys
[11:17] <highvoltage> yes, thanks!
[11:17] <jml> ddaa: btw, I've asked you a question in another channel
[11:17] <ddaa> nice, I won't have to go break the lock by hand on the server :)
[11:17] <dholbach> rock
[11:22] <dholbach> thanks again guys
[11:25] <ubotu> New bug: #116367 in malone "Apport should be able to report private bugs" [High,Confirmed]  https://launchpad.net/bugs/116367
[11:30] <ubotu> New bug: #116369 in malone "Apport should be able to subscribe people to bug reports" [High,Confirmed]  https://launchpad.net/bugs/116369
[12:20] <kiko> good morning
[12:20] <carlos> kiko: hey, hey, hey!
[12:21] <kiko> how's it going today, carlos?
[12:22] <carlos> kiko: fine
[12:22] <kiko> that's great to hear
[12:22] <carlos> kiko: everything landed (well we got a reject due to a conflict but it's already landed)
[12:22] <carlos> kiko: danilos is testing it on carbon
[12:23] <carlos> jtv is applying some review comments and I'm working on the UI change
[12:23] <kiko> overall very good
[12:23] <carlos> indeed
[12:23] <danilos> kiko, carlos: on a combination of staging and carbon, we'll be pointing staging to a DB on carbon so we have full power over it
[12:24] <kiko> danilos, so you can check the UI, etc, right?
[12:25] <danilos> kiko: that's right, to make sure we are hiding what we are supposed to be hiding
[12:26] <kiko> very good.
[12:29] <Hobbsee> yay, kiko!
[12:46] <kiko> hey Hobbsee 
[12:46] <Hobbsee> :)
[12:46] <kiko> make it stop raining please kthxbye
[12:47] <Hobbsee> rain, stop.  good rain.
[12:47] <Hobbsee> just come to au.
[04:01] <BjornT> time for this week's non-au reviewer meeting
[04:01] <BjornT> == Agenda ==
[04:01] <BjornT>  * Roll call
[04:01] <BjornT>  * Next meeting
[04:01] <BjornT>  * Queue status.
[04:01] <BjornT>  * pre-mentor reviews should be sent to launchpad list (barry)
[04:01] <BjornT>  * encourage more pre-implementation reviews (barry)
[04:01] <BjornT>  * if overwhelmed, push back to general queue (barry)
[04:01] <BjornT>  * Other Business
[04:02] <BjornT> who's here?
[04:02] <flacoste> me
[04:02] <salgado> me
[04:02] <barry> me
[04:03] <BjornT> bac: ping
[04:03] <BjornT> statik: ping
[04:03] <bac> me
[04:03] <flacoste> SteveA: ping
[04:03] <SteveA> hi
[04:03] <bac> statik is out sick today
[04:03] <BjornT> lifeless: ping
[04:04] <BjornT> == Next meeting ==
[04:04] <BjornT> next meeting will be 2007-05-30 at 1400 UTC
[04:05] <BjornT> == Queue status ==
[04:05] <BjornT> there are 13 open reviews, 7 of them are over the 2 day service target.
[04:05] <BjornT> SteveA: you have an old one, that's not really a code review. what's the status of that one?
[04:05] <salgado> I'm doing one of them already
[04:06] <BjornT> salgado: cool
[04:07] <SteveA> BjornT: thanks, I'll look at that today after this meeting
[04:08] <BjornT> salgado: do you know it statik has started reviewing cprov's branch? given that statik is sick, we should re-allocate it.
[04:09] <salgado> BjornT, I don't think he has, but I can't tell for sure
[04:09] <salgado> he was on holidays last week and I didn't chat with him since then
[04:10] <LarstiQ> the +reject text on questions mentions a couple of categories, but not bogus. What should I do with a question like https://answers.launchpad.net/bzr/+question/7070 ?
[04:10] <BjornT> ok. my queue is empty, so i'll take it from him to review it later today.
[04:11] <BjornT> == pre-mentor reviews should be sent to launchpad list ==
[04:11] <flacoste> LarstiQ: retargeting to ubuntu is a safe bet
[04:11] <BjornT> barry: ^^^
[04:11] <kiko> bjornT, barry: +1
[04:11] <SteveA> the launchpad-reviews list
[04:11] <SteveA> and the code's author
[04:11] <barry> so, steve and i were talking yesterday and i mentioned about the odd situation where a review is at your mentor
[04:11] <SteveA> just like a regular review
[04:12] <barry> right, so for those of us being mentored, send your reviews to the list instead of your mentor privately
[04:12] <barry> then mark your branch needs-reply or whatever
[04:12] <barry> and let your mentor comment on your review on the mailing list
[04:12] <BjornT> ok, that sounds good to me. +1
[04:12] <SteveA> and mark the email at the top saying clearly "this review is provisional, subject to mentoring"
[04:12] <barry> SteveA: +1
[04:12] <SteveA> like, 95% of it will be valid or whatever
[04:13] <SteveA> so the author can start work on responding anyway
[04:13] <flacoste> +1, this will improve the flow
[04:13] <barry> right, and so the author has a better idea of what the state of his branch is
[04:13] <bac> i've been using "MENTOR REVIEW: barry/blah/blah" as the subject
[04:13] <flacoste> and it would also help us meet service level
[04:13] <kiko> maybe say [NEWBIE REVIEWER]  or something silly like that
[04:13] <SteveA> say it in the body of the email
[04:13] <bac> +1 on sending to the lsit
[04:13] <barry> REVIEWBIE
[04:14] <kiko> nice
[04:14] <SteveA> it's easy to miss important information in a mail subject
[04:14] <barry> i think it's fine just to say "this review is subject to mentor oversight" or some such in the body of the review
[04:14] <SteveA> right
[04:14] <barry> doesn't have to be that formal really
[04:15] <barry> next item?
[04:15] <BjornT> ok, looks like we have an agreement.
[04:15] <BjornT> == encourage more pre-implementation reviews ==
[04:16] <barry> SteveA: do you want to take that one?
[04:16] <SteveA> is there any doc on mentoring code reviewers we need to update?
[04:16] <SteveA> so, we have development cycles now
[04:16] <barry> SteveA: i'm not sure there are /any/ docs on mentoring reviews
[04:16] <SteveA> and I want to encourage more pre-implementation reviews
[04:16] <SteveA> even for bugs / features that the implementer things don't need it
[04:17] <SteveA> it's easy to have a call saying "I think this is obvious, what do you think?"
[04:17] <SteveA> and the reviewer saying "yeah, it's obvious"
[04:17] <SteveA> that takes like 5 mins
[04:17] <SteveA> but sometimes, the reviewer will point out important stuff
[04:17] <SteveA> like, someone else on the team is working in a similar area
[04:17] <SteveA> or, that the *scope* of the work isn't quite right, and that benefits from some discussion
[04:18] <SteveA> or there's a new technique to test this that the implementer may not know about yet
[04:18] <SteveA> for small things, 3-4 pre-implementation reviews can be put into one 15 minute call
[04:18] <SteveA> so, when you're reviewing some code, always ask "who did the pre implementation review?"
[04:19] <SteveA> if it had such a review, then it's likely to be easier to do the pre-merge review
[04:19] <SteveA> one valuable thing to get out of a pre-implementation review is
[04:19] <SteveA> a succinct description of what the work is about
[04:19] <kiko> LarstiQ, ping
[04:19] <SteveA> like, it's one sentence summary of how the work will be going
[04:20] <LarstiQ> kiko: pong
[04:20] <barry> i think the one thing we have to work out is how to allocate reviewer resources so that 1) no reviewers get overloaded with pre-impl reviews; 2) authors know who to go to to get pre-impl reviews /before/ they start hacking away
[04:20] <SteveA> and that's valuable for doing the pre-merge review, to ask "so, did anything change in your approach once you started working on it?"
[04:20] <SteveA> that's all I have to say on this for now
[04:21] <SteveA> I'd like to see whether a branch has had a pre-implemnentation call marked on the pending reviews or w-i-p entry for it
[04:21] <BjornT> i think that's a good idea, i found such calls useful in the past.
[04:21] <SteveA> it's useful for joey to know about this for his project tracking
[04:21] <barry> +1 on the concept, i just think we need to work out the workflow
[04:21] <BjornT> i'd rather add something to PendingReviews to indicate who did the pre-implementation call, than to ask it when a code review is done.
[04:22] <bac> my call with SteveA before my last feature implementation was very useful.  +1
[04:22] <flacoste> BjornT: that would also make it possible to see on pending-branch-summary to see the pre-impl status
[04:22] <BjornT> i think figuring out how to encourage people to have such calls is importants, since we used to have them in the past, but we don't have them anymore (or only rarely)
[04:23] <kiko> bjornT: I think the monthly release process can help there
[04:23] <BjornT> kiko: how?
[04:24] <bac> BjornT: the greater visibility you suggested on the PendingReviews page would encourage calls if it is seen as an expected part of the process
[04:25] <kiko> bjornT: every first week of the cycle, we're going to agree upon specs for the next month. and then we can follow the specs in a much more linear fashion
[04:28] <BjornT> ok. so let's start with adding a field to PendingReviews, and see how it works out.
[04:28] <barry> crazy idea: i wonder if we shouldn't encourage non-reviewers to get involved in pre-impl calls too?  iow, /all/ launchpad devs would be available for such calls.  okay, they won't be as experienced, but this will get them acclimated to the process and they can always escalate to a reviewer or more experienced dev if need be.  that also reduces the load on reviewers
[04:29] <flacoste> barry: i like the idea, it's kind of virtual pair design
[04:29] <barry> flacoste: exactly
[04:30] <SteveA> a three-way conf call can work well too, when the work affects various areas of the code
[04:31] <SteveA> we have to work out different things for different cases, depending who is available, and what the feature's about
[04:31] <BjornT> it's definitely better to have a call with a non-reviewer than to have no call at all
[04:31] <SteveA> in all cases, as bjorn says, some call is better than no call at all
[04:31] <barry> cool
[04:32] <salgado> I think this should be an item for tomorrow's developer's meeting
[04:32] <salgado> just to notify people, that is
[04:32] <flacoste> right
[04:32] <barry> salgado: +1
[04:33] <BjornT> well, we should send a mail to the list as well.
[04:33] <BjornT> any volunteer for updating the pending branch template on PendingReviews, send a mail to the list, and bring it up on the meeting tomorrow?
[04:35] <barry> i suppose since i brought it up i should do it :)
[04:35] <SteveA> note that this can't be just a new status
[04:35] <SteveA> I want to be able to see when I review some code that the call occurred earlier
[04:35] <flacoste> SteveA: it should be a new field, like the demo url for example
[04:36] <BjornT> SteveA: i was thinking if adding a field like 'Pre-implemenation call: (who)
[04:36] <barry> BjornT: agreed
[04:36] <SteveA> +1
[04:36] <barry> can i bring up one other thing now that we're talking about the template?
[04:36] <SteveA> as a shorter name
[04:36] <SteveA> we could call it a prep-call
[04:36] <SteveA> or something like that
[04:37] <BjornT> barry: sure. i think this item is done anyway.
[04:37] <barry> minor issue: i would like the author to include their email address in the template (even if it's just the local name part).  i find it difficult sometimes to match the branch name to the canonical email address
[04:37] <barry> this will get harder as we get more devs
[04:38] <SteveA> the name we use on devpad should work as an email address
[04:38] <SteveA> if that doesn't work in any of the cases, then we need to either get an email address alias added
[04:38] <SteveA> or change that name on devpad
[04:38] <SteveA> thanks for pointing that out barry
[04:38] <barry> SteveA: okay.  cool, knowing that rule, i can fix my script :)
[04:39] <BjornT> == if overwhelmed, push back to general queue  ==
[04:39] <SteveA> barry: if you find any instances where this doesn't work, tell the owner of the email address / branch, and cc Rinchen who can track it
[04:39] <SteveA> if it means getting an alias added, or changing that name
[04:39] <barry> SteveA: will do
[04:39] <SteveA> we should also update the "rocketfuel setup" docs
[04:40] <SteveA> to include this policy
[04:40] <SteveA> salgado: would you take on that?
[04:40] <salgado> sure
[04:40] <SteveA> thanks
[04:40] <SteveA> sorry BjornT 
[04:41] <SteveA> so...
[04:41] <barry> BjornT: i mentioned to steve the guilt i felt about clearing my queue.  he said, figure out how much time you're going to spend on reviews and do what you can during that time.  if you can't finish them, push them back to the general queue (stevea, did i paraphrase that accurately?)
[04:41] <SteveA> yes
[04:41] <SteveA> reviewers should set aside a portion of their day / week to work on reviews
[04:41] <SteveA> and in general, never do more than that
[04:41] <barry> then, if we need more reviewers or need to make other adjustments, we'll know what to do
[04:42] <SteveA> there are times when we need more review done, and we can trade off time spent reviewing against other work
[04:42] <SteveA> that trade-off should be done *mindfully*
[04:42] <SteveA> in general, a reviewer who has been given too much to do should push the excess back into the process, for reassignment
[04:43] <SteveA> that's my feeling on the matter.
[04:43] <barry> SteveA: it'll also probably shift during the release lifecycle
[04:43] <BjornT> i think we'll have to have some sort of process to deal with this, though, so that some reviewers don't simply push their work to other reviewers.
[04:43] <jthomas> is it known that bug reports aren't working on Launchpad?  Neither manual nor Apport..
[04:44] <BjornT> when a deadline approaches, every reviewer is usually quite busy, both reviewing, and finishing their own work.
[04:44] <barry> BjornT: another thing, i think we should constantly (or maybe, regularly) looking to recruit reviewers
[04:45] <BjornT> i.e., i think most reviewers should set aside an more or less equal amount of time.
[04:45] <barry> BjornT: maybe another thing to do is to agree informally on the amount of time a reviewer should be spending on reviews
[04:45] <SteveA> so, every 2 month devel cycle
[04:45] <SteveA> at the end of the cycle
[04:45] <barry> reviewbies might get less done in that amount of time, but they will become more efficient as they get more experienced
[04:46] <jthomas> is it known that bug reports aren't working on Launchpad?  Neither manual nor Apport..
[04:46] <SteveA> let's evaluate membership of the review team
[04:46] <barry> SteveA: +1
[04:46] <SteveA> Rinchen: hi, are you there?
[04:46] <Rinchen> yes sir
[04:46] <SteveA> what do you think about having a standard time in the devel cycle where we look at membership of the review team
[04:47] <SteveA> particularly to recruit new members
[04:47] <SteveA> it could be around the time of the minor release
[04:47] <SteveA> or some other time
[04:47] <barry> BjornT: what do you think is a reasonable amount of time (as a goal) per week to devote to reviews?  4h?
[04:48] <salgado> jthomas, do you get an error when you try to? can you explain what happens to me in private as we're in the middle of a meeting?
[04:48] <matsubara> jthomas: privmsg me explaining what's going please.
[04:48] <Rinchen> It's not a bad way to operationalize that need.  It would probably be good to do that during the time we're planning for the next cycle...say week 6-8
[04:48] <Rinchen> Lessons learned from the previous 6+ weeks will be fresh in our minds
[04:49] <jthomas> salgado and matsubara: sorry to interrupt, i don't know how to private message, meet in #launchpad-bad please?
[04:49] <SteveA> Rinchen: great, let's try that.  please add it to the calendar.  basically it's having nominations sent to the review team leader, then having a meeting of the review team to decide what to do with the nominations.
[04:49] <lifeless> bjornt [pong
[04:49] <salgado> I think Rinchen can help us to define a reasonable amount of a time we should devote to reviews every week
[04:50] <BjornT> lifeless: i was pinging you for the reviewer meeting, in case you wanted to join in.
[04:50] <lifeless> that would be good. we have ben tracking the time taken in the review messages for   awhile
[04:50] <salgado> based on the amount of time people reported to have spent on reviews in the past weeks
[04:50] <lifeless> BjornT: I do, I do
[04:50] <SteveA> I suggest (based on nothing but a gut feeling), start with 90 mins per day available, and see how it goes for a couple of weeks...
[04:51] <flacoste> i have a dedicated review time each day
[04:51] <flacoste> at the end of the day just after tea break
[04:52] <lifeless> the push back mechanism is already explicitly declared; people do need to follow it though - perhaps there is a psycological bias against saying 'I'm overloaded right now' ?
[04:53] <BjornT> yeah. i've found it the past that other reviewers have pushed back their work, and i've felt bad for doing the same, since that would overload the remaining reviewers too much
[04:53] <BjornT> i think it's better to have something more or less clearly defined, so that we can decide whether we need more reviewers.
[04:55] <lifeless> its been on my todo to do the math based on the reivews list for a while. If Rinchen can do It I'll be very grateful
[04:56] <BjornT> i usually forgot to note down how long re-reviews took, though.
[04:56] <salgado> how about we keep reporting the time we spent on reviews every week and then a few weeks from now we establish (based on these numbers) a reasonable amount of time people should spent reviewing. then when you've spent all your review time for a week and still have branches on your queue you'd push them to the general queue
[04:56] <salgado> somebody with free review-time could pick them up
[04:57] <Rinchen> I've been saving the data from the weeklies so I can attempt to plot out something simple and compare it with the volume on the queue. The key factor is going to be that there will be two heavy review weeks - one before each release week.
[04:57] <salgado> if they're left on the general queue it means we need to increase the time people spend doing reviews or the number of reviewers
[04:57] <lifeless> salgado: I think it should happen daily. doing it weekly I feel will produce jags of high latency branches for people
[04:58] <Rinchen> For the record, I am not in favour of letting reviews stagnate on the needs-review queue.
[04:58] <kiko> nobody wants that
[04:58] <lifeless> Rinchen: I think no-one is.
[04:58] <salgado> lifeless, yeah, that'd be much better
[04:58] <lifeless> Rinchen: can you process the current numbers and give an estimate of review-time-total-per-week?
[04:59] <lifeless> Rinchen: that at least ballparks it
[04:59] <Rinchen> lifeless, yes sir. 
[05:00] <Rinchen> I don't know how easy it will be to compare that to branch sizes but I'll poke around to see if I can find an easy way to do that too.  I'd love to have a metric for this.  e.g.  For every 200 lines of diff, it will take 30 mins of a reviewer.
[05:01] <SteveA> well
[05:01] <lifeless> Rinchen: we have that data at the time of the review; I dont know that we preserve it. It may be that we should ask the review to note the count from pending-reviews in the eview.
[05:01] <SteveA>  + and change lines are harder than - lines
[05:01] <lifeless> that said, I have a very strong feeling that its non-linear
[05:01] <SteveA> and reviewing tests is different from reviewing application code
[05:01] <BjornT> IME, it's definitely non-linear
[05:01] <SteveA> for tests, you're reviewing whether it is truely testing functionality, and testing the right functionality
[05:02] <Rinchen> yes, I also believe it's non-linear.
[05:02] <SteveA> for app code, you're reading whether it makes sense and hangs together well
[05:02] <barry> and if you fire up launchpad.dev and poke around on u/i, it can also be pretty time consuming (but i think very useful too)
[05:02] <Rinchen> I still would like to approximate that though if it's easy enough to do. 
[05:02] <BjornT> the larger the diff is, the more times i have to go through the whole diff to understand the changes.
[05:02] <Rinchen> right
[05:05] <BjornT> ok, i guess that's enough discussion on this subject for now.
[05:05] <BjornT> == Other business ==
[05:05] <BjornT> anything else?
[05:06] <SteveA> I want to announce that I found a great line in "waiting for godot" by samuel beckett
[05:07] <SteveA> Estragon: Oh, tray bong, tray tray tray bong.
[05:07] <SteveA> could come in handy in code reviews.
[05:07] <barry> SteveA: while doing code reviews?
[05:07] <lifeless> nice
[05:07] <lifeless> terrible accent though
[05:07] <barry> :)
[05:08] <kiko> waiting for godot is depressing
[05:08] <kiko> why are you mentioning it here, SteveA?
[05:08] <SteveA> I don't think it is depressing.
[05:09] <kiko> I find that even more depressing
[05:10] <BjornT> i must have missed that line, or it might not have been present in the lithuanian version of that play
[05:11] <BjornT> anyway, meeting ended. thanks for being here!
[05:11] <barry> BjornT: thanks!
[05:12] <flacoste> thanks BjornT!
[05:12] <SteveA> thanks everyone.  I think we made a lot of progress in this meeting.
[05:16] <kiko> yes
[05:17] <kiko> we made many electrons move through the wires!
[06:31] <ubotu> New bug: #116452 in malone "Malone Can't Handle Large File Attachments" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116452
[06:45] <ubotu> New bug: #116454 in malone "Add a milestone view for an IProject" [Undecided,Confirmed]  https://launchpad.net/bugs/116454
[06:48] <kiko> thanks bjornT
[07:09] <HlTMAN> hi
[09:34] <LaserJock> kiko: you around?
[09:34] <kiko> yep
[09:34] <kiko> how are you jordan?
[09:34] <LaserJock> oh fine
[10:00] <mpt> Gooooooooooooooooooooood morning Launchpadders!
[10:01] <mpt> And a wonderful morning it is, no more flooding
[10:09] <radix> hooray
[10:41] <SteveA> kiko: hi
[10:42] <kiko> SteveA!
[10:43] <kiko> SteveA, I'm going out. I'm tired of this office!
[10:57] <lifeless> Sarah_ has your nick gotten confused
[11:03] <matt001> Hi, I have a question on Updatde OpenPGP Keys under my profile on Launchpad.
[11:05] <thumper> morning
[11:09] <matt001> I have created an OpenPGP key.  If I ever reinstall my operating system, will I loose this key of my computer?
[11:12] <LarstiQ> matt001: I'd very much encourage backing up your (secret) key to a safe offline medium.
[11:15] <matt001> thank you LarstiQ
[12:07] <surak> I have a question.. May a shareware project use launchpad's structure?
[12:10] <bac> surak: Launchpad is for open source projects.
[12:11] <bac> surak: What is the project you'd like to host?
[12:11] <surak> that's an official position? I saw shareware products which later opened to foss
[12:11] <LarstiQ> What exactly does shareware entail in this context?
[12:11] <surak> bac: it's not me. The main developer of MailPlane is interested on launchpad's bug management system
[12:12] <bac> surak: Please have the developer contact us here on IRC so we can see what we can arrange.  Is it in his plans to open the project in the near future?
[12:13] <surak> MailPlane is a macos-only application which turns gmail in a sort-of desktop application. It handles mailto: links, drag-and-drop attachments and so on
[12:14] <surak> bac: I have no idea if he plans to open the application, unfortunately. As most of mac shareware, he will probably make some money on it before :)
[12:15] <bac> surak: OK.  If Ruben is interested in pursuing it, please have him contact me.  Thanks!
[12:16] <surak> Do you know him? Or just saw the name on webpage?
[12:16] <bac> surak: just checked out his web page.  :)