#ubuntu-reviews 2010-05-03
<dholbach> good morning
<ajmitch> morning dholbach
 * ajmitch will reply on time one day
<dholbach> hey ajmitch
#ubuntu-reviews 2010-05-04
<nigelbabu> persia: ok, so tomorrow is patch day,who does the starting delights? :)
<nigelbabu> err, today rather
<nigelbabu> bdrung: just reminding you that patch day starts today :)
<nigelbabu> nhandler: ^
<nigelbabu> who else to remind now
<nhandler> Thanks nigelbabu
<nhandler> Where is the schedule?
<nigelbabu> https://wiki.ubuntu.com/PatchDay
<nhandler> thanks
<nhandler> nigelbabu: One thing we might want to do is poke the next reviewer when it gets close to their turn
<ajmitch> good to see all the slots filled now
<dholbach> good morning
<persia> Patch Day! Patch Day! Patch Day!
<persia> So, this is the beginning of patch day.  The 5th of May is slowly winding itself over the globe.
<persia> Who all's here?
 * vish never seen persia so excited ;)
<persia> hey vish.
<vish> hi..
<BlackZ> hey persia
<persia> Hey BlackZ.
<persia> So, 330 outstanding patches seeking quick review: https://bugs.launchpad.net/~ubuntu-reviewers/+subscribedbugs
<persia> Let's get that down to 0 by the end of today.  We've almost 50 hours, so if we can do better than one patch every 10 minutes, we win!.
<ajmitch> hi all
<persia> Hey slytherin, popey.  Welcome!
<slytherin> :-)
<popey> o/
<persia> So the list of patches we're trying to clear today is https://bugs.launchpad.net/~ubuntu-reviewers/+subscribedbugs
<persia> https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide is a guide to how we review the patches.
<persia> There's other informative links in the /topic if you're curious :)
<kermiac> hey ppl - I've never done patch review before but I'm willing to give it a shot :) is there anything I can help with?
<persia> kermiac: Absolutely.  We've a little over 300 patches we're targeting today.
<persia> https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide is the procedure we're using: just grab any bug to which ~ubuntu-reviewers is subscribed, and have at it.
<vish> yay , knocked one out..
<kermiac> ok, I'll have a look. Thanks persia :)
<persia> Hurrah vish!
<vish> persia: hmm , Bug #111939 , has the debdiff , earlier sponsors [ bdrung ] mentioned there was no debdiff , but now we have one , we can unsubscribe the reviewers and subscribe the sponsors right? also nigelbabu has spoken about this bug to didrocks
<ubot3> Malone bug 111939 in metacity "Not possible to alt-tab during a drag-and-drop operation" [Unknown,Confirmed] https://launchpad.net/bugs/111939
<persia> vish: Needs a maverick patch at this point, as well.
<vish> ah.. ok
<persia> vish: If yo'd like, you can probably easily convert nigelbabu's lucid-proposed debdiff to maverick, and then drop it from our queue.  Looks like it's already upstream, so would probably benefit from some tags.
<yofel> hm, what needs to be done on bug 154349? correct the tags?
<ubot3> Malone bug 154349 in synaptic "synaptic won't remember certain preferences" [Undecided,Confirmed] https://launchpad.net/bugs/154349
<persia> yofel: Looks like it's tags only there, yeah.
<persia> yofel: Might be able to just drop from the queue, depending on the upstream status of the patches.
<yofel> mvo merged it into lucid but not trunk yet (as said on https://code.edge.launchpad.net/~oliver-joos/synaptic/lp154349/+merge/23250)
<yofel> would that be accepted or sent?
<persia> I think just patch-forward-upstream: needs to have been merged to be patch-accepted-upstream
<yofel> ok
<yofel> remove the patch tag or leave it?
<bdrung> vish: yes (subscribing ubuntu-sponsors)
<persia> leave it.  Otherwise it just gets added again and the team resubscribed.
<yofel> ok
<vish> persia: hmm , i think nigelbabu already has the debdiff for that too..
<bdrung> nigelbabu: do the review team recommend DEP-3?
 * persia didn't see if, but if it's there, yeah, bdrung is right.
<vish> ah yay.. bdmurray just replied ;)
<vish> oopd bdrung ^
<persia> bdrung: We don't really care: we focus on getting patches to upstream, mostly.
<persia> bdrung: https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow
<bdrung> persia: getting patches upstream does not conflict with using DEP-3 header.
<yofel> persia: tagged, the workflow says to unsubscribe the reviewers team now, can you do that?
<persia> bdrung: Right, but we don't insist on it: we assume that it's best to pass the patch around with appropriate attribution, regardless of the format.  DEP-3 is more important in the context of getting a patch applied as a distro-patch than in the context of ensuring communication with usptream is happening.
<persia> yofel: Sure.  154349, right?
<yofel> yes
<persia> yofel: Done.
<yofel> thanks :D
<yofel> next one...
<persia> Damascene: Are you finding everything you need?
<bdrung> persia: yes. IMO a reference or recommendation for DEP-3 in the reviewguide would be nice.
<Damascene> persia, I found out that I'm not a member of bugsquad nor understand how to make .deb files
 * yofel didn't know about DEP-3, will read it later
<persia> bdrung: Do you really think it's relevant for patches that aren't being applied at a distro-level?
<bdrung> persia: i think it's useful. You have the link to launchpad in the patch.
<persia> OK.  You do know that we don't expect patch authors to read the reviewers guide, right?
<bdrung> persia: yes. the member of the review team could add the header (at least when he/she creates a debdiff)
<persia> But generally we *don't* create debdiffs.
<persia> We mostly just forward the patches upstream.
<persia> (the exception being patches to distro-patches or packaging, but those don't generally get DEP-3 anyway)
<ajmitch> persia: so where the patch comes from upstream via the debian maintainer, and it's only SRU material (mysql), does the review team need to be subscribed?
<persia> ajmitch: In cases like that it's be nice of us to debdiffise it and push to sponsors, but not, that doesn't need us to do anything.
<persia> s/not/no/
<ajmitch> well it's being handled by a server team member
 * ajmitch isn't in the team, so can't unsub
<persia> In that case, we don't need to care about it at all: just add the tags (patch-accepted-upstream, etc.) and move on.
<ajmitch> bug 343870 if you want to take it off the list
<ubot3> Malone bug 343870 in mysql-dfsg-5.1 "php-cli segmentation fault with mysql extension" [Medium,Confirmed] https://launchpad.net/bugs/343870
<persia> Sure.
<persia> Done.
 * dholbach adds ajmitch
<persia> dholbach: Thanks!
<dholbach> blogged about it too http://daniel.holba.ch/blog/?p=678
<ajmitch> dholbach: ta
<persia> hey duanedesign!
<yofel> how would one handle bug 251335? part of the patch was accepted, part  of it needs work, the bug is tagged as patch-needswork already
<ubot3> Malone bug 251335 in synaptic "Synaptic searches on UI thread" [Medium,Confirmed] https://launchpad.net/bugs/251335
<persia> yofel: I'd probably call that "patch-forwarded-upstream" and "patch-needswork".
<persia> yofel: Shall I unsub the team for that one?
<yofel> I think yes (at least that's what I believe after reading the review guide)
<persia> Done.
<persia> So we've finished the first hour of patch day, and are already 6% complete.  At this rate, we'll be done in 16 hours!
<ajmitch> persia: the 312 that's showing is a bit high, too
<ajmitch> as multiple bug tasks on the same bug show up in the list
<persia> ajmitch: Sure, but since I started with the 330 number (also a bit high), I figure it's only fair to compare against that.
 * persia tries to convince LP to provide a more correct number
 * ajmitch tries to decide what to do about this bug
<persia> Which bug?
<ajmitch> bug 551901, it's sort-of-but-not-quite upstreamed
<ubot3> Malone bug 551901 in krb5 "likewise-open fails to join Windows 2000 SP4 domain" [Medium,Confirmed] https://launchpad.net/bugs/551901
<ajmitch> again, being handled by the server team people :)
 * ajmitch is going for familiar territory in the list
<persia> Probably the same: needs tagging, and unsubscription.  Bugs well-in-hand tend to just need gentle poking.
<ajmitch> ok
<ajmitch> I think I'll get back to this tomorrow, a little late for me to think straight this evening
<persia> Thanks!  Have a good night.
<persia> https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-reviewers seems to be the URL for the lower-number (but I don't have the count from the start of Patch Day).  201 now.
<persia> Anyone looking for instructions, or buglists?
<persia> nigelbabu: Are you about?
<yofel> persia: can you unsubscribe the team from bug 33288? nigelbabu seems to have forgot about it (and should one re-ad the patch tag for those bugs?)
<ubot3> Malone bug 33288 in poppler "Evince doesn't handle columns properly" [Unknown,Confirmed] https://launchpad.net/bugs/33288
<persia> yofel: I don't see the point of re-adding the patch tag, personally.
<yofel> ah wait, there's no patch on it anymore right
<persia> dholbach: Could you add yofel to the team?  He seems to have a good handle on the process :)
<dholbach> yofel: is your launchpad id yofel too?
<yofel> yep
<dholbach> super
<persia> Thanks.
<dholbach> done
<yofel> thanks :D
 * persia pokes nigelbabu again
<persia> Hey hyperair!
<hyperair> hey persia =)
<persia> hyperair: Would you be up for starting a bit early?  nigelbabu doesn't seem to be about.  We're down to 200 according to https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-reviewers and 309 acording to https://bugs.launchpad.net/~ubuntu-reviewers/+subscribedbugs  (from 201 at 11:00 and 330 at 10:00)
<hyperair> heh? it's already review day?
<hyperair> =O
<hyperair> i need to be running at 9pm, though, it seems.
<hyperair> that'd be in 1.5h
 * hyperair goes to grab some dinner first
<persia> Of course, and you're listed as next on https://wiki.ubuntu.com/PatchDay :)
<persia> Of course, and you're listed as next on https://wiki.ubuntu.com/PatchDay :)
<hyperair> i swear i thought that was 24h from now.
<persia> The 5th of May is creeping around the globe :)
<hyperair> oh looks like i put my name in for today as well!
<hyperair> =O
<hyperair> okay i'll go look at things
<persia> Looks like you're also scheduled for 24h from now.
<hyperair> yes, i am
 * hyperair kicks java
<hyperair> uh what do i do if launchpad decides to hate me today?
<hyperair> it's been hating me a lot recently
<persia> Ask for help?  Lots of folks are active and doing stuff, so if you can't get somewhere, I'm sure someone else can.
<persia> Main thing you need to do during your shift is make sure people know about https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-reviewers and https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide and answer any questions that come up.
<persia> also, maybe good to post statistics at the top of each hour, and make sure you coordinate with the next person on the schedule when the time comes.
<hyperair> okay
<persia> Thanks for starting early!
<hyperair> persia: is there an easy way to filter only bugs affecting packages *i* can upload to?
<nigelbabu> I'm here, sorry to be late
<hyperair> \o/
<nigelbabu> hyperair: you're on now?
<yofel> hi nigelbabu
<nigelbabu> hey yof
<hyperair> nigelbabu: no, you're on.
<nigelbabu> hyperair: ok.  the wiki shows you, since you covered for me, gladly
<yofel> can someone double check bug 202009? IMO that's not a patch, but a scritpt that somehow workarounds the issue changing the default and user settings while at it
<ubot3> Malone bug 202009 in grub "update-grub not updating menu.lst" [Medium,Confirmed] https://launchpad.net/bugs/202009
<nigelbabu> heya yofel (didn't tab earlier)
<persia> hyperair: Not that I know.
<hyperair> persia: =(
<r0tes_pf3rd> when do the patch-day start?
<nigelbabu> r0tes_pf3rd: we've started already
<r0tes_pf3rd> oh, cool
<r0tes_pf3rd> how can i help?
<nigelbabu> r0tes_pf3rd: You can help by reviewing patches.  I'll point you the documentation so you can start off
<nigelbabu> https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide
<nigelbabu> 182 untouched bugs to go, so there's still plenty out there :)
<r0tes_pf3rd> ok, i will look on the page
<nigelbabu> yofel: I think we have something similar to that grub bug already
<nigelbabu> i.e. a fix is already in I think
<nigelbabu> from karmic on I remember only 1 kernel being displayed on boot
<BlackZ> hey jono
<nigelbabu> hyperair: you cool for next hour?
<yofel> nigelbabu: well, I do remember the discussions about menu.lst not updating in karmic, but I'll leave the bug handling to someone that knows a bit more about grub, do you agree though that that's not a patch?
<hyperair> nigelbabu: unfortunately not. got a meeting at 9pm (45min from now)
<nigelbabu> hyperair: wait, so you're taking care of this hour or you want me to?
<nigelbabu> yofel: agreed there, its a new script
<hyperair> nigelbabu: er. up to you, which do you prefer?
<jono> hey BlackZ
<nigelbabu> hyperair: I did around 20 minutes to prepare a presention for UOW, either now or next hour
<nigelbabu> s/did/need
<hyperair> alright, go do it, i'll handle this hour =)
<nigelbabu> hyperair: thank you, poke if you need something, I should be around :)
<hyperair> nigelbabu: sure.
 * hyperair regrets not remembering set theory and curses java's weird transformation API
<nigelbabu> anyone think its worth it to update review lead on topic?
<nigelbabu> dholbach: about?
 * persia thinks it's not worth updating the /topic for every change, as it's likely to be more flexible than scheduled.
<nigelbabu> yeah, hence I didn't d it
<nigelbabu> do it
<nigelbabu> hyperair: ok, taking over :)
<nigelbabu> Folks, 180 bugs unreviewed in the queue.
<nigelbabu> I'll be the review lead for the next few hours
<nigelbabu> bdrung: I've been lazy to follow dep-3 on that metacity bug since I wanted someone to first test
<nigelbabu> persia: do we want to advertise in -bugs and -motu every 6 hours or so?
<nigelbabu> hello fschrat
<persia> I'd say 4, but sure.
<nigelbabu> persia: hm 4 is fine too :)
<nigelbabu> malev: hey, nice to see you here, Patch day is today!
 * hyperair grumbles
<fschrat> hello everyone
<hyperair> i spent all my time trying to test that chkrootkit patch
<hyperair> turns out chkrootkit hung trying to read /proc/kmsg
<malev> hi nigelbabu ! I'll start in a few minutes
<nigelbabu> hyperair: awesome
<nigelbabu> fschrat: hey, welcome
<nigelbabu> malev: great :)
<nigelbabu> persia: can take a look at http://launchpadlibrarian.net/40823731/vncExtInit.cc.patch ?
<nigelbabu> isn't the patch file formatted wronly ?
<persia> No, just differently.  We're used to looking at the output of `diff -u ...`: that's the output of `diff ...`
<nigelbabu> oh, ah
<nigelbabu> looks like I need to test tht bug
<nigelbabu> what would be the call on bug 424927? leave it for jfo?
<ubot3> Malone bug 424927 in linux "include CK patch set (BFS)" [Wishlist,Confirmed] https://launchpad.net/bugs/424927
<dholbach> nigelbabu: yes
<persia> Indeed.  It's in one of the blacklisted packages, but left over from before the blacklist was in place.
<nigelbabu> oh, then I have some cleaning to do
<nigelbabu> dholbach: you'll be around for my session right, just in case I cna't handle questions
<dholbach> nigelbabu: around that time I was planning to meet somebody for dinner :-/
<dholbach> nigelbabu: what about bdmurray and james_w and bryce?
<nigelbabu> dholbach: I'll talk to james
<dholbach> better ping all of them :)
<nigelbabu> yeah, good idea
<nigelbabu> bdmurray, james_w:  My UOW session on patch review is at 1700, if you folks can be around to help with questions, would be great :)
<dholbach> nigelbabu: I have an idea for when the patch day is over: we could start making a list of bugs that were solved where the patch reviewers put some time into fixing them and we blog "the story of these patches" later on
<dholbach> (a bit like https://wiki.ubuntu.com/BugSquad/Diaries)
<nigelbabu> dholbach: I'm +1, I actually want to ask brian for a tar of all the mails in moderate on the patch review m/l during patch day
<nigelbabu> moderation queue
<nigelbabu> dat way we can know who did what
<nigelbabu> Status update: 172 unreviewed bugs
<nigelbabu> heya arand :)
<arand> nigelbabu: Hello, hmm, I'm likely not going to be of much help, but I though I might listen and learn, it that is ok?
<nigelbabu> arand: sure :)
<nigelbabu> ok, good news
<nigelbabu> we have gone below 170 mark
<nigelbabu> 167 unreviewed bugs
<nigelbabu> hello there dyfet
<nigelbabu> would you like to help with patch review?
<dyfet> I would be happy to try
<nigelbabu> dyfet: great! you can go through https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide
<nigelbabu> please ask if you have any qiestions
<nigelbabu> there is always a review lead here till the end of patch day
<nigelbabu> heya qense
<nigelbabu> we're down to 160 unreviewed bugs folks :)
<qense> hi nigelbabu!
<nigelbabu> qense: patch day today!
<qense> My congratulations to the review team!
<qense> aha!
<nigelbabu> qense: another 40 hours or so to go
<yofel> meh, what's the policy if someone adds an upstream patch to a bug?
<qense> Huh? How long is your definition of a day?
<nigelbabu> yofel: if its integrated upstream, add patch-accepted-upstream
<yofel> ok
<nigelbabu> qense: a day in all time zones, 49 hours
<qense> Good idea :P
<qense> So for my timezone the day's actually tomorrow!
<nigelbabu> qense: haha
<yofel> for me too, but who cares :P
<nigelbabu> qense: see, you should be inspired by yofel :D
<qense> I'm already working very hard on Mergimus!
<qense> Even though it's not Write an App-day!
<nigelbabu> qense: lol
<nigelbabu> starcraftman: /ws 29
<nigelbabu> grrr
<malev> anyone choose a patch as they want or there is a sort of order or something like that?
<nigelbabu> malev: have you seen the query link on review guide
<nigelbabu> just take a pick from that query
<nigelbabu> it should show you all unreviewed patches
<malev> this is the query: All open bugs with patches attached: https://launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.s
<malev> ubscriber=&field.component-empty-marker=1&field.tag=&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_no_package.used=&field.has_patch.used=&field.has_patch=on&field.has_branches.used=&field.has_no_branches.used=&field.has_no_branches=on   ?
<malev> sorry, it's a big query
<malev> I'm here: https://wiki.ubuntu.com/ReviewersTeam/KnowledgeBase
<malev> and I take the query from there
<nigelbabu> not that one, let me find it
<nigelbabu> malev: click on query here https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow
<nigelbabu> malev: to start off you can go with bug 569469
<ubot3> Malone bug 569469 in update-manager "[lucid] program crashes when string "%s ago" is displayed" [Medium,Fix committed] https://launchpad.net/bugs/569469
<nigelbabu> it seems easy enough
<malev> nigelbabu, oks! going there
<nigelbabu> malev: so, what do you make of the situation there
<malev> I'm trying to reproduce the bug
<malev> oh there is nothing to reproduce, it's only bad english :D
<malev> gonna check the patch
<malev> nigelbabu, which branch should I download to chech the patch?
<nigelbabu> malev: I'm just checking tht up
<nigelbabu> malev: https://launchpad.net/update-manager
<malev> yes, but, if you go to branches, there are a lot! which onw
<malev> the development?
<malev> or the lucid?
<malev> https://code.launchpad.net/ubuntu/+source/update-manager
<nigelbabu> if you notice the bug, mvo talks about trunk
<nigelbabu> so you should check the trunk brach
<malev> cool
<malev> nigelbabu, you are giving a talk in a few minutes?
<nigelbabu> malev: the 3rd session today
<nigelbabu> malev: if you didn't find the commit yet, its commit 1807
<malev> nigelbabu, I'm downloading the branch. It0's REALLY solw
<nigelbabu> yes, because of maverick stuff
<nigelbabu> malev: when hunting for commits, its easier on the web interface
<malev> nigelbabu, might be, but, how can I test the patch if I don't use it?
<nigelbabu> string changes are kinda easy to predict looking at the code :)
<nigelbabu> bdrung: poke
<yofel> anyone got a minute to look at bug 491940? would that be accepted or needswork o.O? LTSP seems to be happy with the patch, Chris not
<ubot3> Malone bug 491940 in ltsp "Patch for LTSP clients to properly reboot/shutdown" [Undecided,Confirmed] https://launchpad.net/bugs/491940
<yofel> and are we seriously supposed to get subscribed just to package a patch? (not that I mind, I'm just not sure there)
<nigelbabu> yofel: yes, thats part of we do
<nigelbabu> packaging patches
<malev> lauchpad is down?
<yofel> good
<nigelbabu> yofel: talk to chris and hear his take on it (especially after lxde accepted a similar patch)
<nigelbabu> malev: checking
<nigelbabu> malev: nope
<malev> don't now is working
<malev> nigelbabu, I donwload the trunk and it's on commit 1817 ten more than what the web site says...
 * nigelbabu stabs loggerhead
<nigelbabu> malev: what is 1807 about?
<malev> I'm with the patch of update-manager. I can't aply the patch. don't know why
<malev> 1 out of 1 hunk FAILED -- saving rejects to file Desktop/UpdateManager1.py.rej
<malev> bzr: ERROR: Patch application failed
<malev> I think I'm using a different branch
<nigelbabu> malev: you can't apply because the code changed
<nigelbabu> mvo applied another change to fix the same issue
<nigelbabu> and second thing, look at the path you're trying to patch, it doesn't exsit
<malev> that is what I was looking now!
<malev> well, I'm going to try to create another patch with a good path :D
<malev> I start enjoying this :D
<nigelbabu> malev: you dont need to, it would still fail
<nigelbabu> because like I said, mvo already fixed it :)
<malev> ooo too bad
<malev> then I'll close the bug :(
<nigelbabu> no no
<nigelbabu> just change tag to patch-rejected
<nigelbabu> say in comments that another fix for this has been commited already
<malev> because.. it's all ready fixed
<malev> oks
<malev> thanks
<nigelbabu> getting a feel for the process now?
<malev> haha
<malev> I think
<malev> there are some bug reports with doesn't has a patch attached but has the patch tag. should I delete the tag?
<nigelbabu> bug number?
<yofel> sometimes a patch is just pasted into a comment, check for those too, or the patch is upstream and only a link to the commit is given
<nigelbabu> Status update: 155 bugs to be reviewed
<malev> Hey I am in a BR that: It has a bug, but there is newer verstions in which it is fixed. so the OR recomend us to apply the patch or to update the version provided. what do you whink?
<malev> https://bugs.launchpad.net/ubuntu/+source/python-scipy/+bug/538774
<ubot3> Malone bug 538774 in python-scipy "scipy.io.loadmat() excessively slow (regression)" [Undecided,Fix committed]
<nigelbabu> malev: there is not talk of an upstream commit, ask OP for a link to upstream commit to confirm its fixed
<malev> nigelbabu, ok
<nigelbabu> cyphermox: all yours in 10 minutes
<nigelbabu> and be ready to handle a huge influx after the UOW session
<cyphermox> yup
<cyphermox> hi!
<nigelbabu> status update, 154 unreviewed bugs
<bdrung> nigelbabu: pong
<lucasmocellin> hi
<lucasmocellin> I'm customizing a Ubuntu distro for distance learning, and the main point is to apply online tests. I would like to know if there is someone involved to version control in Ubuntu, mainly related to "what/how it happens" when canonical upgrade a ubuntu version like from 9.10 to 10.04. I would like to upgrade my distro and keep an easy control of everything modified.
<cyphermox> well, I have to get going, sorry I can't stick around longer
<ajmitch> morning all :)
<persia> cyphermox: Sorry about that.
<persia> Good morning ajmitch
<ajmitch> how's the patch day going?
<ajmitch> I see you're booked in for an extra-long session now
<persia> Depends on how one counts.  Down to 277/175 bugs left to track 12 hours in.
<persia> Yeah, seems like nobody else was up for being the named contact during these hours :)
<ajmitch> sorry, it sort of falls in my work hours as well :)
<persia> Understood.  Mine too, but I don't mind answering some questions on IRC (and expect the number of folk around to be light for most of it)
<ajmitch> yes, thanks for stepping up todo it
<persia> nigelbabu has a handy way of helping people up the steps :)
<persia> OOh.  only 152 bugs by another count.  I defintely need to use the right queries, I think.
<ajmitch> which count are you using now?
<persia> 152 is the number from the query at https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow
<ajmitch> ok, so that doesn't show the tasks fixed in ubuntu but still pending in debian, which is probably what we want
<persia> It also doesn't show a lot of the bugs that have already been properly tagged and forwarded, etc.
<ajmitch> I should clear up that krb5 one that I asked you about last night
<ajmitch> and apt-xapian-index, I can ask upstream about that directly
<ajmitch> it's useful to have a few active developers in the NZ loco channel
<ajmitch> quite a few of us are DDs in there
<persia> Indeed.
<persia> I have to run off for a bit: I'll definitely answer any unanswered questions when I return.  Apologies for anyone who gets stuck in the meantime.
 * ajmitch will be around, sort of
<persia> Thanks :)
#ubuntu-reviews 2010-05-05
<nigelbabu> Status update: 141 bugs :)
<micahg> how much longer will people be around?
<persia> uGH.  cHANNEL FAILURE :(
<nigelbabu> till tomorrow 1000 UTC
<persia> And it's 0:00 UTC on Patch Day! As the 5th of May begins to cross the Atlantic, we've 141 bugs with patches left in the queue.
<persia> That was supposed to be in *this* channel 10 minutes ago :(
<nigelbabu> hehe :)
 * micahg might be able to do one or two in a couple hours
<persia> micahg: The idea being that Patch Day is happening as long as it's 5th May *somewhere* on the planet.  We're not geographically biased :)
<persia> Cool!
<persia> nigelbabu: Do you happen to have the count that is now 141 from before we started?
<nigelbabu> persia: 183 or 185
<persia> So we're 23% done.  Thanks.
<nigelbabu> to think we had gotten down to 100 something a few weeks back and I worried about running out of bugs
<persia> heh.  There's always folks submitting new patches.
 * micahg needs to make a few SRU patches...
<persia> Hey mannyv!
<nhandler> Looks like I'm up in about 10 minutes
<persia> If you like :)  I thought you weren't scheduled for 0100 UTC until tomorrow.
<nhandler> persia: Oh, you're right :) That works better for me, as I can get ClaseBot finished up for UOW-es ;)
<persia> Heh, go for it.  If you've time later, I'm unsure about how well I can cover the 0600-1000 span, but that may be too late for you.
<arand> For Bug #538747 is patch-needswork and patch-forwarded-upstream appropriate? (and unsubscribe) -- Patch was sent upstream, where decision was made to delay inclusion until it was fixed up to handle both input and output of SI units.
<ubot3> Malone bug 538747 in gparted "gparted should use SI prefix instead of IEC prefix as default" [Undecided,New] https://launchpad.net/bugs/538747
<ajmitch> looks like the count is slowly coming down
<persia> arand: Looks right to me, yeah.
<persia> ajmitch: slowly, but we're roughly on-trend.
 * ajmitch found one where he could do the debian upload & fix other bugs, takes some time :)
<arand> Ah, one must be a prt of reviewers team to unsubscribe them, right? (If anyone would care to on above bug..)
<persia> Sure.  Done.
<arand> thanks
<micahg> so, what are the rules?
<micahg> nigelbabu: do I need to be added to reviewers to do this?
<persia> micahg: You don't.
<persia> https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide are the rules
<persia> There's a link ("query") under workflow that shows the pieces in play (currently 137)
<persia> micahg: making sense to you?
<micahg> persia: yeah, I'm looking at one now
<persia> Cool.
<micahg> persia: what if another team is supposed to review the patcg?
<micahg> *patch
<persia> Do you have an example?
<micahg> like security team in the case of my bug
<micahg> bug 570128
<ubot3> Malone bug 570128 in firefox-3.5 "apparmor profile blocks Sun Java plugin" [Undecided,Confirmed] https://launchpad.net/bugs/570128
<persia> Ah, good example.  That's an Ubuntu-specific bug, so we need to push to Ubuntu.  Yeah, coordinate with the security team on that one.
<micahg> persia: can you unsub reviewers and I'll sub security?
<persia> Sure.
<persia> Do you know that the security team prefers to receive bugs by subscription?  I'd hate to see that get lost.
<micahg> yes
<micahg> in this case
<persia> OK.  Just wanted to make sure.  I don't know much about their procedures.
<micahg> persia: yeah, I talked to jdstrand about these bugs, he usually jumps on them pretty fast
<persia> Great, then it's just mistargeted.
 * ajmitch unsubs -reviewers from bug 570209, should get fixed in debian soonish
<ubot3> Malone bug 570209 in muine "muine about page links to a domain squatter homepage" [Undecided,New] https://launchpad.net/bugs/570209
<persia> \o/
<ajmitch> it needs an FTBFS fix anyway, easiest to do mono stuff in debian & sync it
<micahg> can someone unsub reviewers from bug 512615
<ubot3> Malone bug 512615 in firefox "fonts are incorrectly rendered due to not using system cairo" [High,Fix released] https://launchpad.net/bugs/512615
<persia> Sure.
<persia> micahg: Was that patch ever sent upstream, or shouldn't it be for some reason?
<micahg> persia: hmm, good question, I don't think upstream mozilla wants it, they'd prefer upstream cairo to get it
<micahg> that's a whole mess
<micahg> is -reviewers also a placeholder for upstreaming?
<persia> That's primarily what we do, actually.
<micahg> ok, good to know
<persia> We don't presume to understand all the code, but we know how to test, and we know how to push upstream.  So generally we confirm the bug, confirm the patch works, and make sure upsteam can review it to adopt or drop.
<persia> If you want to handle this specific bug differently in your role as part of ubuntu-mozillateam, I'm happy to unsub the reviewers.  If you want to get reviewers unsubbed by acting as a reviewer, it ought be upstreamed first, etc. so it doesn't get lost.
<micahg> k, leave it there for now, what should really happen is the Ubuntu cairo patch get upstreamed
<micahg> then we won't have to patch our source or mozilla's
<persia> Then there should be an upstream cairo task on that bug :)
<persia> Or is that a different bug?
 * persia reads the bug log harder
<micahg> persia: different bug
<micahg> freedesktop 10301
<ubot3> Freedesktop bug 10301 in freetype font backend "LCD filtering patch" [Normal,Reopened] http://bugzilla.freedesktop.org/show_bug.cgi?id=10301
<persia> Right.  No point in us reviewing that bug then: it's all done.
 * persia unsubscribes
<micahg> it was a hack that we were kinda forced to do since our system cairo is patched and mozilla wants us to use their cairo in the build
<persia> Ugh, yeah.
<micahg> if you can any mozilla stuff in teh queue, feel free to ping me
 * persia looks quick-like
<micahg> I didn't see any in the list tonight
<micahg> save the one we already took care of
<persia> Dunno if bug #570812 counts :)
<ubot3> Malone bug 570812 in chromium-browser "Use the ubuntu startpage by default" [Undecided,Confirmed] https://launchpad.net/bugs/570812
 * micahg doesn't know chromium yet :/
<persia> I don't see anything else offhand.
<micahg> k, if something comes up feel free to ping me
<micahg> should I idle in here?
<persia> If you like.  If not, if we're pushing something into mozillateam, we'll come find you :)
<persia> And if you have time, we'd always apprecitate help with reviewing other patches.
<micahg> k, well, I feel I'm already spread too thin and after UDS, I'm going to have a lot more to do
 * micahg needs to learn to recruit and delegate
<persia> OK.  Stop by if you find time, or if you can reserve some for the occasional patch days.
<micahg> k
<persia> Just past 3:00 UTC, with 135 patches left to go.  We're 37.1% done!
<persia> Err, 27.1% (I can't do math)
<ajmitch> doing wel so far
<persia> A little below trend, but this is a historically slow time of day.  I think we still have a chance.
<ajmitch> bug 3179094 looks like nothing patch-worthy, it's just hardware info being collected
<ajmitch> bug 317094
<ubot3> Malone bug 317094 in xf86-input-evtouch "meta bug to collect lshal touchscreen info" [Undecided,Incomplete] https://launchpad.net/bugs/317094
<ajmitch> hm
<ajmitch> might help if I look at all 200+ comments
 * persia pokes ogra about it
<ajmitch> it was autotagged as having a patch, nothing useful
<ajmitch> I'll remove the tag & subscription
 * persia removes the patch flag from the evtouch_hal.out attachment
<ajmitch> ah, I didn't spot you could do that
<persia> On the right side, if you click "edit" for the attachments.  When there's a patch, there's a special "patches" box with just patch attachments.
<ajmitch> right, I'm just having LP timeout again
<persia> Hey RAOF!
<RAOF> persia: Yo!
<persia> Today is https://wiki.ubuntu.com/PatchDay so we're following https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow
<persia> We're nearly 30% done with the current target query.
<RAOF> Is that query the one from the Workflow wiki?
<persia> Yep.
<persia> 4:00 UTC on https://wiki.ubuntu.com/PatchDay !  Only 133 bugs left to review.
 * ajmitch imagines that many of the easy ones disappear first
<persia> heh
<persia> Anyone have an opinion about whether the patch in bug #570908 is a reasonable solution?  makes it unbootstrappable, but it's already bootstrapped, and the changelog can usefully hint how to rebootstrap.
<ubot3> Malone bug 570908 in vala "Unable to build for PPA when there are patches to vala source" [Undecided,New] https://launchpad.net/bugs/570908
 * ajmitch had looked at that, but didn't know what the ramifications of the change would be
<persia> 5:00 UTC, and we're down to 130 bugs, meaning we're 29.8% complete!
<persia> ajmitch: Yeah.  Looks to me like it's just including the source as well as the built stuff as references, but I'm not sure it belongs upstream: feels like a distribution-bootstrapping-workaround thing to me.
<ajmitch> working around the fact that we only have sourceful uploads
<ajmitch> so not even needed for debian
<ajmitch> (depending on whether they start throwing away binary uploads)
<persia> Oh, right.  Ubuntu-specific indeed.
<persia> Actually, might be needed for Debian, as valac is Arch: any
<persia> (unless someone constructs an N-architecture .changes file, but that's just madness)
<ajmitch> what, like binary porters do?
<ajmitch> ask lool about it, he's in Uploaders
<persia> Good idea :)
<ajmitch> though it looks like slomo does most of the vala uploads in debian
<persia> I haven't seen slomo around in Ubuntu channels in ages though.
<ajmitch> nor have I
<ajmitch> time for me to get a bus home, I'll be back for more patching action soon
<persia> Hey NCommander
<NCommander> hey persia
<persia> It's https://wiki.ubuntu.com/PatchDay !  We're following https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow on submitted patches.
<persia> About 30% done with our current target, but many hours to go.
<micahg> persia: didn't we decide that apport bugs are reported in Ubuntu only or did that change?
<persia> Oh, my mistake.  I missed that decision.  Feel free to Invalidate the usptream task :)
 * micahg searches for email
<NCommander> persia: who's the best person for pointing someone at creating QA tools?
<micahg> persia: idr where it is, maybe double check with hggdh in a few hours
<persia> bug #569792
<ubot3> Malone bug 569792 in apport "wish, alternative available for apport-bug" [Wishlist,New] https://launchpad.net/bugs/569792
 * NCommander notes the retracer explodes if there's an upstream task attached
<micahg> no, that I know :)
<NCommander> well
<NCommander> LP explodes
<NCommander> Makes a nice traceback
<persia> NCommander: Hrm?  More detail is required, but you might want to ask in #ubuntu-quality to hit the right audience.
<persia> Hrm.  We're probably going to get in trouble for using ubuntu-qa@lists.ubuntu.com at some point.  That's *supposed* to be the Qatar LoCo list.
<NCommander> persia: maybe move it to ubuntu-quality-assurance, and then give Qatar ubuntu-qa, or maybe just have qatar be ubuntu-loco-qa?
<persia> Dunno.  Not a battle I choose to fight now.  When the Qatar LoCo team gets active, something will happen.  Anyway, I've unsubscribed the reviewers from 552575
<NCommander> persia: hrm, I can't unsubscribe the reviews team per the wiki.
<NCommander> persia: can you do that with https://bugs.edge.launchpad.net/ubuntu/+source/klibc/+bug/527720 as well? I assigned myself to it as I have a personal interest in fixing it so I'll handle follow ups once the patch is tested
<ubot3> Malone bug 527720 in klibc "thumb2 porting issues identified: klibc uses mov.*pc" [High,Won't fix]
<NCommander> ...
<NCommander> ugh
<NCommander> I hate when that happens
<persia> Sure.
<NCommander> persia: https://bugs.edge.launchpad.net/ubuntu/+source/mountall/+bug/537133 - here's another one. mountall is Ubuntu-specific (no separate upstream, no patch to forward)
<ubot3> Malone bug 537133 in mountall "mountall issues with NFS root filesystem" [Medium,Confirmed]
<persia> And here some of us thought all the easy ones were done already :)
<NCommander> persia: https://bugs.edge.launchpad.net/ubuntu/+source/software-center/+bug/433838 - another one we can remove, Ubuntu specific, no separate upstream
<ubot3> Malone bug 433838 in software-center "Use an icon in the location bar" [Low,New]
<persia> nigelbabu: What do you think about thse cases: should they get patch-forwarded-upstream?
<maco> hi
<persia> Hey maco!
<maco> im looking at the bugs that are tagged as having patches accepted upstream and going "oh look thingies to sponsor!"
<persia> It's https://wiki.ubuntu.com/PatchDay ! We're following https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow on submitted patches.
<persia> heh.  That works too :)
<maco> but umm... is maverick open yet?
<persia> Although most of them would probably be better served by merge/sync at this pont.
<maco> there's a merge that needs sponsored
<persia> https://launchpad.net/ubuntu/maverick/+queue?queue_state=1 says you can upload, but it will wait until later to be processed.
<persia> That will be empty from archive-open to archive-freeze
<maco> yeah i looked at the https://wiki.ubuntu.com/ReviewersTeam/GettingInvolved and clicked the "bug query" link
<maco> empty?
<persia> Yes.  UNAPPROVED only ever contains anything when the archive is frozen.
<persia> If the archive is unfrozen, apprvoal is automatic, so it goes to NEW or ACCEPTED directly.
 * NCommander fires up a Debian chroot to test a bug
<NCommander> persia: where's the handy forward to BTS script?
<maco> ahh ok
<persia> NCommander: submittodebian?
 * maco waits for maverick pbuilder to come into existence
<maco> hmm intrepid's gone eh? guess i can nuke that one
<maco> oh apparently i already did
<persia> always good to plan in advance :)
<maco> persia: are you one of the sru team people?
<persia> I'm not.
<maco> my brain seems unwilling to remember who's on which special teams beyond jdong is on sru team, scottk & riddell on release team, and cjwatson seemingly having every magical power available
<persia> https://launchpad.net/~ubuntu-sru/+members
<persia> https://launchpad.net/~ubuntu-release/+members
<persia> etc.
<porthose> persia, would you please add me to the Ubuntu-sponsors team :)
<persia> (this is why we have a team management interface :p )
<persia> porthose: Sure.
<porthose> persia, thx
<maco> yeah i know :P ive looked at the sru team member list twice today. cjwatson & jdong were still the only ones that stuck
<maco> and jdong sticks because ive been using #ubuntuforums and #ubuntuforums-mods to poke him on sru stuff for a long while :P
<NCommander> persia: I thought we just had one for forwarding something to the BTS without a package
<NCommander> persia: basically a bug CCer
<persia> I don't know of any.  The BTS doesn't like not having a package, version, etc.
<maco> so pitti, slangasek, the 2 i know, and 2 i dont know. k.
 * ajmitch returns, is the list empty yet?
<NCommander> persia: fair enough. You can unsubscribe https://bugs.edge.launchpad.net/ubuntu/+source/distcc/+bug/511585
<ubot3> Malone bug 511585 in distcc "Unable to start pump server because of python version mismatch" [Medium,Confirmed]
<maco> 125?
<maco> is that down from the 1800?
<maco> or is this a subset?
<ajmitch> subset
<persia> It's a subset.
<maco> oh ok
<persia> Down from 185 when patch day started though, so good progress.
<persia> It's specifially all the new patches that haven't been reviewed since a magic date.
<maco> i will poke akk with a pointy stick for her to help out
<persia> if we run out, we'll move the magic date :)
<persia> maco: Thanks!
<maco> she's :( about bugs not getting fixed and i told her this is how she could help
<ajmitch> if we run out, we've done something right
<persia> Indeed.  Getting the patches to the folks that can use them is key to getting the bugs fixed.
<ajmitch> even if sometimes it's us wearing a different hat
<maco> ajmitch: well part of this is getting the patches to upstream too
<maco> because we likely dont want to hold the deltas forever
<persia> The goal of the team is to get the patches to people who can use them.  If people who can use patches join the team and get the patches directly, that also works :)
<ajmitch> maco: I know, I'm talking about wearing a debian hat & fixing stuff there, while passing onto upstream :)
<maco> ajmitch: oooh debian hat, i see.
<maco> very spirally, looks nice on you ;-)
<ajmitch> goes with the debian tartan, you know
<maco> i saw they were getting more debian tartan for debconf this year
<maco> but the options are kilt or necktie
 * ajmitch lives in a city where kilts are sometimes seen on the streets
<persia> maco: Kinda, but most of it is about getting the patches *somewhere*: there's too many patches that get missed because nobody understands, etc.
<maco> pretty sure i'd be considered a cross dresser if i wore either of those :P
<maco> persia: taught akk a couple weeks ago about the magic of the sponsor queue
<persia> maco: It's a matter of culture.  Neckties are perfectly acceptable female attire here.
<maco> persia: sailor suits!
<ajmitch> kilts are worn as part of girl's school uniforms here, funnily enough
<persia> Is one extreme example.
<persia> here also.
<ajmitch> the joys of living in a city settled by scots :)
<maco> ajmitch: catholic school i went to had kilts in grades 4-8 for girls....or a skort... but they weren't tartan, they were solid navy
<persia> kilt+necktie+shirt+optional sweater
 * ajmitch thinks we're almost off-topic here :)
<maco> yep
<persia> Only 125 left.  Nearly one-third done!
<persia> Unfortunately, I've run against a time-wall, and was scheduled for lots more hours as contact than I could do today (and wasn't able to rearrange things).
<persia> If someone else could answer any questions from new folks for a while, I'd appreciate it.  Extra points if you want to fill some of the blanks at https://wiki.ubuntu.com/PatchDay
<persia> Also, if someone wouldn't mind posting the counts hourly or so: it would be nice to make a graph showing how well we did when PatchDay ends.
<maco> if launchpadlib wasnt horribly scary, id suggest scripting that and running it hourly
<persia> There is a script.  It doesn't complete within an hour :)
<maco> O_o
<persia> The script does some other stuff too though, so maybe it's overcomplex :)
<maco> still 125
<dholbach> good morning
<ajmitch> morning dholbach
<dholbach> hey ajmitch
<nigelbabu> Hello folks, second day of patch day today!
<nigelbabu> We have 122 open and unreviewed bugs in review queue waiting for review :)
<nigelbabu> we need to deal with situation where we're going to go against upstream decisions
<nigelb> hyperair: you're up next right?
<hyperair> yeah
<Guest54184> sorry, I'm out of power at home
<dholbach> nigelbabu: how did the session go?
<Guest54184> dholbach: it was nice, finished fast and too lots of questions
<nigelb> now, thats better
<nigelb> dholbach: send most of the development doubts to you ;)
<nigelb> maco helped me with questions and thankfully the storm was out before the session
<dholbach> awesome
<nigelb> hyperair: do you have the number of bugs handy?
<hyperair> nigelb: what number?
<nigelb> hyperair: number of unreviewed bugs
<nigelb> bdmurray: graphs a bit stale?
<nigelb> maco: launchpadlib is not *that* scary
<nigelb> well, here we go 121  bugs
<nigelb> dholbach: thanks for the blog post yday ( I just read it today), perhaps I need to blog today about how much progress we made in 2 days
<dholbach> nigelb: definitely
<hyperair> nigelb: no i don't have a number. is it needed?
<nigelb> hyperair: just post every hour, so we can look at the logs and make a graph for later
<hyperair> okay
<nigelb> helps identify fast hours and slow hours
 * nigelb adds blogging to list of things to do
<hyperair> looks like my hours are going to be slow >_>
<hyperair> launchpad hates me
<hyperair> give it a query, wait 15 minutes for it to load...
<hyperair> or it just won't load at all.
<nigelb> ouch, give me 15 mins, I'll check back home whts the situation
<nigelb> if power is back, I'll do the posting for ya
<hyperair> bah, i can't even get a list of bugs out
<hyperair> =.="
<hyperair> okay, it seems there are 121 outstanding
<persia> nigelbabu: How do you mean when we're going against upstream decisions?
<nigelbabu> persia: no, sorry.  my mistake
<hyperair> persia, nigelbabu: what do i do when i encounter a patch that is not relevant? i.e. it works around the issue somewhere else rather than fixing it in the problematic app
<persia> example?
<hyperair> https://bugs.launchpad.net/ubuntu/+source/gnome-themes/+bug/542240
<ubot3> Malone bug 542240 in gnome-themes "Icons clipped in the indicator applet" [Undecided,New]
<hyperair> the patch patches the theme, but i think the issue is in indicator-applet
<hyperair> as mentioned by the comment i just posted
<persia> I'd say "patch-needswork" for that, if you're comfortable saying it's the wrong way to solve the issue.
<persia> If you're unsure, pass it to upstream for a declaration.
<nigelbabu> I hate a potential patch-rejected bug, but I fear backlash
<nigelbabu> s/hate/have
<hyperair> heh
<hyperair> i know that feeling
<persia> That's the nice thing about patch-needswork: it invites discussion.  patch-rejected should only be used when it's confirmed wrong, and there's some other way to do it in process.
<hyperair> (almost)hourly report: 115 bugs..
<nigelbabu> The bug is actually a Won't Fix thing
<nigelbabu> so we took the middle path, marked it triaged and reported upstream
<hyperair> lol
<nigelbabu> upstream removed a feature and people want it back and naturally blame us
<hyperair> i once had the misfortune of having to argue with someone about a graphical application logging information on the terminal.
<nigelbabu> ouch
<nigelbabu> I like upstream gnome devs attitude on bug trackers
<nigelbabu> the moment you talk about offtopic or blame game on bugs, they will warn you, quite sternly
<nigelbabu> when was the last time we spammed -bugs and -motu?
<hyperair> heheh
<nigelbabu> about time, wanna do the honors hyperair ? ;)
<hyperair> nigelbabu: what honours?
<hyperair> i did it 5 minutes ago.
<hyperair> the hourly report thing
<nigelbabu> ooh, nice :)
<nigelbabu> no no, we just pop by and advertise in the -motu and -bugs channels every 4 hours
<hyperair> o rly
<hyperair> what do i advertise?
<nigelbabu> Just a reminder, it's Patch Day. Anyone with some time to review patches and help get them in the right places is encouraged to stop by #ubuntu-reviews and help out.
 * hyperair copypastas
 * nigelbabu dents and tweets and facebooks
<hyperair> there we go.
<nigelbabu> heya geser, Nicke
<Nicke> hello
<nigelbabu> It's https://wiki.ubuntu.com/PatchDay  ! We're following https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow on submitted patches.
<micahg> persia: security team picked up the apparmor bug this morning :)
<persia> Great!
<nigelbabu> amazing
<hyperair> 112 bugs..
<nigelbabu> ooh, 70 bugs done :)
<persia> 73!
 * nigelbabu fails in subtraction
<persia> Which makes us 40% done.
<hyperair> \o/
<persia> With 21 hours to go, we're still roughly on-target if we can maintain a rate of 6 patches reviewed an hour.
<hyperair> cool
<persia> Which is only one every ten minutes.  We can do this!
<dholbach> persia: how many did you do already? :)
<persia> I didn't count.  10 or so.
 * dholbach did a few during patch day lite, but just one during patch day
<persia> There's plenty more :)
<dholbach> yeah
<persia> And not just the hard ones.  ajmitch and I had thought the easy ones were gone, and NCommander stopped by and processed 3-4 with just bug tag adjustment.
<persia> So I suspect there are other ones that are being well-managed, and just not using our procedure (and which therefore show up as "needing review")
<nigelbabu> A couple of easy bugs if soeone wants to have a go
<nigelbabu> bug 568402, bug 540342
<ubot3> Malone bug 568402 in qt4-x11 "Qt displays half width character as full width in some Japanese fonts" [Undecided,New] https://launchpad.net/bugs/568402
<ubot3> Malone bug 540342 in lintian "Lintian strings scripts cannot handle spaces in path names" [Undecided,New] https://launchpad.net/bugs/540342
 * hyperair would be faster if only launchpad responded better
<yofel> hm, about bug 520919: that's a packaging change request that's waiting for a r-base MIR, and it's already assigned to nixternal, here's no upstream involvement at all
<ubot3> Malone bug 520919 in kdeedu "Cantor is missing possibility to add R backend" [Wishlist,Triaged] https://launchpad.net/bugs/520919
 * persia knocks out 568402
<nigelbabu> I think the HIG complaiancy patches are okay to get in
<nigelbabu> Just making the text complaint with upstream HIG, like bug 555213
<ubot3> Malone bug 555213 in hundredpapercuts "Make printer jobs viewer HIG compliant" [Low,Confirmed] https://launchpad.net/bugs/555213
<nigelbabu> thoughts?
<persia> I used to think that, but seb128 pointed out that 99% of the time upstream was happy to take them, and it's painful to carry the divergence.
<persia> So I'd recommend pushing those upstream, rather than seeking to get them into Ubuntu.
<nigelbabu> ok, so anyone wats an easy bug, piack that one, just send upstream :)
<nigelbabu> Also, someone can just forward bug 491940 upstream
<ubot3> Malone bug 491940 in ltsp "Patch for LTSP clients to properly reboot/shutdown" [Undecided,Confirmed] https://launchpad.net/bugs/491940
<nigelbabu> so many easy bugs waiting to be picked
<bdrung> hyperair, nigelbabu: i have to do some work. it would be nice if someone could take the responsibility for the 1700 UTC slot to give me one more hour.
<hyperair> 17 + 8 = 25..
<hyperair> sure no problem
<henne91> hi
<hyperair> hello henne91.
<henne91> ok I'm pretty new to this
<bdrung> hyperair: thanks. your day has 25 hours? ;)
<nigelbabu> bdrung: ouch, I have a very early slot
<nigelbabu> oh well, the rockstar is here :)
<nigelbabu> woo hyperair !
<hyperair> bdrung: it fluctuates between 12 and 48 ;-)
<persia> henne91: So we're following https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow : just ask if you have any questions, or need an opinion or a hand.
<henne91> persia: ok thx I'll take a look at that
<nigelbabu> hyperair: lol
<nigelbabu> 108 bug now :)
<persia> \o/
<persia> nigelbabu: You'll post a pretty graph to your blog when Patch Day ends, right?
<nigelbabu> yes :)
<nigelbabu> oh yeah, blog post to write!
<persia> Better hurry: the 6th of May started 5 hours back, and is moving around the planet at a good clip :)
<henne91> need to go
<nigelbabu> http://justanothertriager.wordpress.com/2010/05/05/flash-news/
<nigelbabu> dholbach, persia: ^
<dholbach> nice
<dholbach> well done
<nigelbabu> folks, 8 more bugs and we enter into double digits
<qense> nigelbabu: There seems to be an inconsistency at <https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide>, the documentation talks about the tags 'patch-forward-upstream' and 'patch-forwarded-upstream'
<nigelbabu> qense: can correct to forwarded please?
<qense> I can do that, yes!
<nigelbabu> thank you :)
<maco> this is akk ^
<maco> akk: this is what we're doing today https://wiki.ubuntu.com/PatchDay
<maco> nobody's announced the count in a few hours. 104
<maco> akk: 185 bugs were targetted to be reviewed today
<maco> akk: https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide  <-- thats the step-by-step
<akk> Cool! Is there any synchronization here, like "Is anyone working on bug 12345 already? I want to take it"?
<ubot3> Malone bug 12345 in isdnutils "isdn does not work, fritz avm (pnp?)" [Medium,Fix released] https://launchpad.net/bugs/12345
<akk> sorry, ubot3 :)
<maco> heh
<maco> i'd say pick randomly from the center of the list
<maco> apparently they set a "magic date" and said "ok we're going to try to get through all patches submitted since $date" and tht turned out to be 185
<maco> james_w: ping
<james_w> hey maco
<maco> james_w: can you have lp:debian/sid/meld resync to match current debian? ive got a merge to do
<akk> Curious what the date was ... I don't see a date in the query there.
<james_w> maco: not easily, as LP is currently prevented from importing source packages to its mirror of Debian
<james_w> you can see that https://edge.launchpad.net/debian/+source/meld/+publishinghistory is out of date
<maco> james_w: why?
<maco> yes i see that its way back at september
<maco> what's wrong with lp?
<james_w> there's some bug
<james_w> I don't know
<maco> oh :(
<james_w> they are supposed to be looking in to it
<james_w> I'm trying a workaround
<maco> i guess as a workaround i could bzr init inside the unpacked debian source package, push that to my-namespace spot in lp, and do the merge that way
<maco> james_w: would that work? im sure if i knew how to manually merge i could do that too, but...
<james_w> give me a few minutes
<akk> Darn, my gmemusage patch was a year ago so it's not on the list.
<maco> apparently not
<maco> akk: you can do something with it anyway :P
<akk> I probably will start with that. :)
 * maco glad crimsun's not in here
<maco> he'd be lecturing me for not knowing how to do a merge without bzr or MoM
 * akk is still wondering when that gimp patch will get pushed into lucid
<maco> akk: the statusbar one? its in lucid-proposed already
<akk> Right, but then there was more bug activity that looked like it was moving into actual lucid ... only it didn't. I'm confused what to look for in bug updates.
<maco> packages spend 2 weeks (i think?) in -proposed so breakage can be caught, then they go to -updates
<akk> Ah! Thanks, I wasn't clear on that.
<maco> says it hit updates 11 hours ago
<maco> https://edge.launchpad.net/ubuntu/+source/gimp
<maco> the really *awesome* bit about my inability to understand how to merge this package is that the program in the package is a tool for merging
<akk> heh
<james_w> maco: try now
<akk> Not just merge as in diff -p1 <goo.diff, I assume?
 * maco hugs james_w
<maco> akk: 3-way merge
<maco> upstream, ubuntu changes, and debian changes
<akk> Oh, yeah, I don't really know how to do that either. Maybe when you fix this package I can use it. :)
<maco> oh i dont know if that package does it, just that that's what i was trying to do
<maco> james_w: thank you :)
<james_w> glad it worked
<maco> bzr's being a little bit ridiculous about this merging O_o instead of the >>>>>> ===== <<<<<< lines surrounding just the few lines that changed, it put the entire old file and the entire new file in
<maco> (if it couldnt resolve something. if it could it was yay)
<james_w> humm
<james_w> odd
 * hyperair wonders if bdrung has returned
<bdrung> hyperair: i am back
<hyperair> yay bdrung
 * hyperair wonders where util-linux's upstraem is
<hyperair> do they have a bug tracker i can stick patches into?
<bdrung> hyperair: LKML?
<hyperair> bdrung: that place sends shivers down my spine ._.
<bdrung> http://www.kernel.org/pub/linux/utils/util-linux/
<hyperair> hmm
<hyperair> but kernel has bugzilla.kernel.org
<hyperair> oh hey maybe util-linux will be there also..
<maco> james_w: hello?
<maco> O_O
<maco> oh. wrong lp page
<maco> davidek: hi! we're having a patch day today
<maco> here's the workflow for what we're doing today https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide and the list of bugs to look at is https://bugs.edge.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-reviewers&field.tag=patch%20-patch-needswork%20-patch-forwarded-upstream%20-patch-forwarded-debian%20-patch-accepted-upstream%20-patch-accepted-debian%20-patch-rejected-upstream%20-patch-rejected-debian%20-patch-rejected&field.tags_combinator=ALL
<davidek> hello! that's the reason, i'm here.
<maco> (goodness that url is looooong)
 * hyperair kicks sbuild
<hyperair> that's why you're supposed to visit the reviewersteam wiki and just click the link
<maco> heh
<maco> hey hyperair, how long does it take for lp to notice when you dput something?
<bdrung> maco: not long (few minutes)
<maco> ok
<maco> and does the automatically-mark-bug-fixed thing happen when the package hits proposed or updates?
<bdrung> IIRC when hitting updates
<maco> ok
<maco> davidek: got any questions?
<maco> or did whomever wrote the wiki page do a good job?
<hyperair> maco: 3 minutes or so i think.
<bdrung> maco: you should mark dputted SRUs as 'fix committed' because the upload will stuck it the queue and manually accepted
<maco> hmm s/whomever/whoever/
<hyperair> maco: updates.
<davidek> maco: not yet
<maco> bdrung: same for things uploaded to maverick while frozen?
<maco> well then again i did commit to bzr so that sounds valid... but i wonder if debcommit means itll mark that automagically
<bdrung> maco: yes
<maco> im gonna wait a few minutes and see if the debcommit/bzr mark-uploaded/bzr push combination does it automagic
<bdrung> if i am right, mark-uploaded just adds a tag
 * maco pokes bzr-builddeb with a Hobbsee's pointy stick
<maco> -S -- -sa? grr
<hyperair> lol
<hyperair> i use aliases
<maco> reading bzr-builddeb --help i thought the --split thing was gonna do it for me magic-like, but nope
 * maco goes to add note to wiki page
<hyperair> bzr always gives yyou that impression.
<hyperair> use git!
<imbrandon> maco: lol@Hobbsee's stick, havent seen that thing fly arround in a while
<ajmitch> morning
<imbrandon> heya ajmitch
 * keffie_jayx missed hobbsee's stick of doom :(
<bdrung> maco: what's  Hobbsee's pointy stick?
<maco> bdrung: a stick (that i have the impression she's sharpened) that she uses to poke people/things on irc
<bdrung> ough, that probably hurts
 * ajmitch hasn't really seen hobbsee around for awhile
<maco> ajmitch: i think school's been kicking her
<ajmitch> quite probably
<ajmitch> she needs to kick back
 * nigelbabu is here!
<nigelbabu> aw no, 1 hour early
<bdrung> nigelbabu: but you are here, right?
<nigelbabu> yes :)
<nigelbabu> @now
<bdrung> nigelbabu: then i can take a shower and you will be there for answering questions
<nigelbabu> bdrung: hehe, go ahead :)
<bdrung> nigelbabu: it has been quite quiet the last hours (= not much to do for me)
 * ajmitch will try & ask some annoying questions then
<nigelbabu> hahah
<nigelbabu> you'll and up answering yourself
<nigelbabu> s/and/end
<nigelbabu> its 3 am here
<ajmitch> 9:24 here :)
<maco> the count is currently 103
<maco> i think akk worked on forwarding patches she's submitted to lp that weren't on today's list
<maco> speak of the devil
<akk> Sorry, busy day.
<nigelbabu> did we go below 100 at any time?
 * ajmitch spots one to unsubscribe
<maco> nigelbabu: i dont think so
<maco> i spent a /lot/ of time doing a fairly simple merge because i kept forgetting how to use things like bzr and bzr-buildpackage
<maco> james_w got me straightened out and then i fixed the wikipage
<ajmitch> maco: what needed changed?
<ajmitch> & yeah, LP not updating its debian info is problematic for merging
<maco> ajmitch: i got to the end of the "how to do a merge" and went "ok...so i push to lp and then...? how do i upload" so yay for the uploading page, added a link to that... and then added a bit thats like oh by the way, you need bzr-buildpackage -S -- -sa -vFOO
<maco> when doing a merge from debian
<ajmitch> which page was this on?
 * ajmitch needs to refresh his knowledge of this stuff :)
<maco> https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging
<maco> i learned about bzr mark-uploaded today
<ajmitch> too much magic :)
<maco> james_w: idea for bzr mark-uploaded: change bug status to "fix committed"
<kklimonda> heh, every time I try using bzr magic to maintain some package the results are terrible and I go back to the packaging branches..
<maco> james_w: actually... no this is more of a lp thing. lp should go "oh look thingy in queue! *fix committed*"
<ajmitch> I think that's in progress now
<nigelbabu> yaay! 99
<ajmitch> bug 318439
<ubot3> Malone bug 318439 in launchpad-code "bzr --fixes lp:xxxx doesn't change the status of the bug" [High,Triaged] https://launchpad.net/bugs/318439
<nigelbabu> it does
<nigelbabu> ajmitch: it makes it fix comitted
<ajmitch> ok, that's useful then
 * ajmitch thought that was still WIP, shows how much I use branches for packages
<nigelbabu> we are now at 96!
 * ajmitch hopes to see it at 0 by lunchtime
<nigelbabu> anyone knows what eucalyptus is about?
<geser> nigelbabu: does it work for all kind of branches or only for upstream branches or packaging branches?
<nigelbabu> geser: ive seen it work for individual branches of a project
<nigelbabu> I dunno for ubuntu development branches, lemme check
<ajmitch> nigelbabu: eucalyptus implements something like amazon's EC2, it's what runs the cloud stuff in ubuntu
<nigelbabu> ajmitch: sh, patch in it, dunno what to do :/
<ajmitch> see if someone in the server team is on it
<nigelbabu> geser: no, ubuntu development branches it doesnt happen
<nigelbabu> ajmitch: smoser?
<nigelbabu> ah yes, server team
<bdrung> nigelbabu: we need a tag for "don't touch this patch, i can handle it myself"
<nigelbabu> bdrung: yeah we need one
<bdrung> for bugs like #369525
<ajmitch> agreed, I've come across a few bugs like that
<nigelbabu> lol, i just played there didnt I?
<ajmitch> yes
<ajmitch> or bugs like bug 276472
<ubot3> Malone bug 276472 in samba "cp -p on CIFS mount does not preserve permissions and returns a permission denied error" [Medium,In progress] https://launchpad.net/bugs/276472
<ajmitch> handled by a kernel team member
<nigelbabu> bdrung: easiest way, just unsubscribe review team without removing patcch tag
<ajmitch> down to 94
<nigelbabu> make that 93
<bdrung> nigelbabu: k, that would work, but then i have to wait until the script subscribed the review team
<nigelbabu> bdrung: if there is a patch tag, we won't be subscribed again
<bdrung> nigelbabu: so adding the patch and adding the patch tag would work?
<ajmitch> when poatches originate from upstream, I guess I should unsubscribe the review team?
<nigelbabu> bdrung: yep
<nigelbabu> ajmitch: patch-accepted-upstream?
<ajmitch> very much accepted, more patch-originated-upstream
<nigelbabu> yeah, use that tag so peole who want to package can spot it
<ajmitch> yeah I was just checking the debian changelog, fix is already in lucid (from debian)
<ajmitch> it's a debdiff for karmic-proposed
<nigelbabu> oh, SRU
<ajmitch> yep, and it's hardly a critical one
<nigelbabu> I'dsay poke someone in sru team to accept or reject
<ajmitch> yes, I was about to
<nigelbabu> ajmitch: always a step ahead :)
<ajmitch> specifically jdong, since the bug/patch submitter is from someone he knows, and he's subscribed
<nigelbabu> oh yaay! 91 bugs to go!
<nigelbabu> bdmurray: are the graphs a bit stale? is it because you're working on updating the script?
<nigelbabu> 89! lets move it folks :)
<bdmurray> nigelbabu: can you show me what you mean by stale?
<nigelbabu> http://qa.ubuntu.com/reports/patches/
<nigelbabu> bdmurray: last update date is 04/28
<nigelbabu> ajmitch: you folks were talking about the vala bug yesterday?
<nigelbabu> what was the final call on that one?
<ajmitch> I was talking with persia about it, I don't know if he talked to lool
<nigelbabu> hm
<ajmitch> I didn't follow up further
 * nigelbabu really wants to see 0!
<nigelbabu> persia: can you followup on the vala bug? since I dunno what to ask ;)
<nigelbabu> 88 bugs, we're dropping constantly here :)
<yofel> another one done
<nigelbabu> yaay!
<nigelbabu> where is everyone? akk? maco?
<akk> Sorry, I'm lurking but I don't think I'll have time to do anything today.
<nigelbabu> akk: ah, no problem :)
<akk> And if I did I'd be awfully tempted to start with my year-old patch that's too old to be in your list.
 * ajmitch can't really do much more for a little while
 * ajmitch wishes he'd got stuff into karmic-proposed long before lucid release
<ajmitch> having people still available to test stuff would be nice
<nigelbabu> akk: you can get it into our list
<nigelbabu> ajmitch: yeah, definitely
#ubuntu-reviews 2010-05-06
<nigelbabu> 82, yaay!
<nigelbabu> nhandler: you're on in 1 hour
<nhandler> nigelbabu: Aren't I going on 01:00 UTC, which is 1.75 hours from how
<nigelbabu> nhandler: wht is utc time now?
<nhandler> nigelbabu: 23:21
<nigelbabu> nhandler: oh no, can you start frm next session, i need to get to work
<ajmitch> nigelbabu: wouldn't you need sleep or something first? :)
<nigelbabu> ajmitch: sleep is over. 2200 to 0230
<nhandler> nigelbabu: I can try, but I'll probably be eating dinner in the middle
<nigelbabu> nhandler: *grin*  ajmitch will be around :)
 * ajmitch may not be around
<ajmitch> that'll be when I head out for lunch (12:00 here)
<nigelbabu> 83 bugs more!
<nhandler> Somehow we'll cover any questions that get asked during that hour, but they might need to wait for answers
<maco> nigelbabu: im helping a guy fix his centos
<maco> im failing :(
<maco> im *trying* to help him fix his centos
<maco> but its a yum b0rk not a things-that-exist-here-too b0rk
<maco> akk: i think the list is "stuff ubuntu-reviewers is subscribed to" and that the magic date is simply the date from which the script that autosubscribes the team was set to run
<nigelbabu> maco: lol, ok.  we're having a gap in coverage due to my excellent math skills thinking gmt = utc
<maco> ah daylight savings got ya?
<nigelbabu> i think so, why is there no desktop tool for time conversion?
<maco> date -u
<yofel> @now
<yofel> :(
<maco> nigelbabu: the date command accepts format strings, such as %Z for the timezone name to be listed
<nigelbabu> maco: ok, so basically its always -4:30 for me
<nigelbabu> well, I'm always at +4:30 from UTC
<maco> right, whereas gmt moves about for british summer time
<nigelbabu> yeah, I usually keep a gmt thingie on my clock and forgot it moved around
<nigelbabu> can someone review 3 more bugs?
<nigelbabu> so we can get to 70?
<nigelbabu> at least I want to make sure we reach the 40s for this patch day :)
<nigelbabu> persia: we need some system to deal with packages that are ubuntu-specific
<nigelbabu> also, can someone test and review bug 564698
<ubot3> Malone bug 564698 in util-linux "lscpu command shows "???" when messages are translated in Japanese" [Undecided,New] https://launchpad.net/bugs/564698
<ajmitch> persia would be good to look at that :)
<nigelbabu> yes, hopefully he will when he sees it :)
<nigelbabu> maco: can take a look at the k-reltaed packages in the list?
<nigelbabu> wow, I spell *bad*
<nigelbabu> ajmitch: wise to defer eucalyptus to server team?
<ajmitch> yes
<nigelbabu> just unsubscribe then?
<ajmitch> I assume so, you're the boss ;)
<nigelbabu> lol, no I'm not :)
<ajmitch> but that bug looks very actively looked at
<nigelbabu> yeah, its assigned too
<nigelbabu> ok, so I'm off, someone please cover and answer questions
<nigelbabu> we're at 82
<nigelbabu> bug 569442
<ubot3> Malone bug 569442 in ttf-wqy-zenhei "After upgradeing to Lucid, unexpectedly-using bitmap font in Japanese Environment (upgrading regression)" [Undecided,New] https://launchpad.net/bugs/569442
 * nigelbabu points to maco ^
<maco> ew yuck. bitmapped japanese. that has to be hard to read
<nigelbabu> bitmapped chineese actually I think
<nigelbabu> check out the bug
<maco> japanese uses chinese characters
<Paddy_NI> Hey maco
<nigelbabu> maco: o_0 thats news to me
<maco> nigelbabu: japanese didnt have a written language. chinese monks gave them literacy
<nigelbabu> maco: wow
<ajmitch> almost down to 1 page of stuff to look at
<nigelbabu> YAAY! We have breached 80
<nigelbabu> Only 79 more bugs to look at!
<maco> Paddy_NI: https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide
<Paddy_NI> thanks maco I was wondering what I should be doing.. perhaps reading the topic :)
<maco> um hmmm
<maco> so one of the wiki pages links to bugs that have been marked accepted upstream or accepted debian
<maco> maybe this query should filter out "fix committed" bugs though, since if its committed in ubuntu, its just waiting for a freeze to be lifted, which most people cant really do anything about
<nhandler> So I guess I'm up now
<nhandler> Nice and quiet now
 * ajmitch is working...
<nhandler> Hmm...Does anyone remember what bugs the script looks for to subscribe the reviewers team to?
<persia> nhandler: I believe the script looks for any bugs with attached patches that have the patch added since a certain date and aren't subscribed to a blacklist of teams and aren't bugs against a blacklist of packages.
<nhandler> persia: Do you know what statuses it looks at?
<persia> I believe all open statuses (not invalid, won't fix, fix released).
<nhandler> Ok, thanks
<persia> The interesting question is: if a bug is Fix Committed and has a patch attached, is this confusion on the part of the person setting the status?
<maco> persia: bdrung told me today that if i upload a package but its sitting in the queue waiting to be approved, then its fix committed
<maco> for -proposed stuff and during freezes
<persia> I guess, but why should it both have an attached patch and *not* be subscribed to a team?
<persia> I think the majority of cases are mistakes: the rare case where it's correct, we can just unsubscribe the team.
<persia> And it's still Patch Day!  We're down to 79 bugs to review, which indicates that we're 58% done.
<maco> what team would be subscribed when its uploaded and sitting in a queue?
<maco> archive admins or something?
<maco> (do they have a team?)
<persia> Depends on the reason for the freeze.
<persia> I'd say the Release Team, generally.
<maco> i uploaded a merge to maverick today thats waiting for toolchain freeze to go away
<persia> So, bug #538774 is an example of a bug in our queue that's Fix-Committed.  Why shouldn't that get patch-accepted-debian and be unsubscribed?
<ubot3> Malone bug 538774 in python-scipy "scipy.io.loadmat() excessively slow (regression)" [Undecided,Fix committed] https://launchpad.net/bugs/538774
<persia> Also, even if an upload is prepared for Ubuntu, should we not be looking at pushing the patch somewhere else (or verifying that this has been done)?
<maco> that's a misuse
<maco> the person put fix committed when they committed to their own branch on lp, but if theyre going to use that it should be when it gets committed to lp:ubuntu/<package>
<persia> How is that different than the case you describe?  It will be closed with autosync in a couple days, much like the case you descibe will be closed with unapproved queue clear.
<persia> Oh, right.  Timing miss.
<maco> timing miss?
<persia> Yeah.  The status was changed for the incorrect reason (making it good we caught it), *but* in later analysis, it has reached a state that matches what you describe.
<maco> oh yeah i looked at the activity log to see how it got there
<maco> i dont think we're doing it like this yet, mostly (though kubuntu does) but committing to lp:ubuntu/<package> bunches of fixes and then only doing a dpkg-buildpackage -S once seems like something thatll be futury
<maco> futurey
<maco> erm..something
<persia> Right.  Anyway, my point is that in case 1: where it's Fix Committed for the wrong reasons, we want it anyway, and in case 2: where it's Fix Committed because it's been uploaded and pending processing, it's not bad for us to get it.
<maco> "get it"?
<persia> "receive the bug in our review queue"
<persia> I've worked on a bunch of packages that do VCS packaging and upload containing lots of fixes by lots of folks, and yes, in that case, Fix Committed makes sense, but I think there's still value in us tracking the patches to ensure that patch communication is happening.
<maco> you mean in terms of upstreams?
<maco> persia: patch communication in terms of what?
<persia> Yeah.
<persia> Basically, I'm not sure how the stuff we do is in any way affected by Fix Committed.
<persia> because none of the automated patch communication stuff takes effect until the upload is processed.
<maco> i think ill go through all the fix-committed's and check to see if theyre improper use and if so put them to the proper status
<persia> I recommend against that.  You'll bump into the Desktop Team, which abuses that status regularly.
<persia> There aren't any more Fix Committed ones in our queue.
<maco> yeah just noticed that when i saw jon the taco and seb128 both use it weirdly
<maco> seems that team uses fix committed in ubuntu in place of upstream bug watches
<maco> persia: my email says to tell you im gonna expire from sponsors soon
<persia> I suspect your email tells you that you're expiring from the obsolete sponsors team, and suggests telling me under the false impression I'm going to let anyone renew :)
<persia> Would you like to join the new, cool, shiny, real sponsors team?
 * persia finds the .m and prepares to click the button, waiting for a response
<maco> hehe yes :)
<maco> the .m?
<maco> is that because lp/~maco != me ?
<persia> Yes.
<persia> The .m is essential
<maco> yeah i dont know lp/maco
<maco> just that they took my name
<maco> thanks
<maco> (just got email)
<persia> Thanks for helping with sponsoring :)
<persia> OK.  5:00 UTC, and we're only down to 78, which is the one I did.  There's lots there, and we've only 6 hours left, which means we need to push fairly hard to finish within the day!
<maco> persia: it went back up to 79
<persia> It did indeed, but shishire is working 485225, and I expect it to go back down soon.
<maco> persia: if a not-right patch is attached to a bug, should we unmark it as a patch or delete it or what?
<persia> example?
<maco> https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/512395
<ubot3> Malone bug 512395 in openoffice.org "Openoffice.org's .desktop files do not contain translation domain info" [Wishlist,New]
<maco> well in this case there are a bunch of "oh no wait this time i got it right..." type things
<persia> I'd call that patch-needswork
<maco> should the old patches be removed?
<dholbach> good morning
<persia> I'd leave the old patches for historical purposes.
<maco> ok
<maco> should they be unmarked so that the patch list on the side only lists the one thats being suggested?
<persia> Hmm.  That's an interesting question.
<persia> I think "No", because I think there's sufficient value in reading the bug log to understand the background.
<maco> ok
<persia> That said, it does add apparent difficulty if one assumes folks just grab from the patch lists and push, but I think doing so is uninformed behaviour, and don't want to encourage it.
<persia> Note that I feel this is a very subjective opinion on my part: I'm not certain it should be policy without wider discussion.
<maco> usually when im going "oops that patch was wrong, heres a fixed one" i delete my previous one from the bug. wasnt sure if that was just me or not
<dholbach> Development and MOTU Q&A Session in #ubuntu-classroom in 17m
<maco> dholbach: pfft nobody in this channel has any interest in development :P
<maco> this channel is for kitten photos!
<dholbach> maco: I hope you're wrong ;-)
<persia> And we kinda compete with MOTU in some ways: seeing who can get the patches applied first
<persia> (to different targets)
<maco> (actually no, #ubuntu-women was the kitten-photo channel earlier)
<maco> cuz we're trying to make it so that all the patches reach ubuntu by syncing from debian?
<persia> Or, better, by inclusion by the original software authors, yeah.
<persia> Mind you, it's a very freindly and cooperative competition :)
<maco> well if its in upstream, itll hit debian then sync to here in most cases
<persia> Right.
<maco> i dont /think/ there's a whole lot that goes straight into ubuntu without passing through debian
<maco> except kde. we get that packaged within a day or two of a new release and then i have no idea how long til debian's got it
<persia> Depends on the area of focus.  Some areas have lots, some not so much.
<maco> mm and the kernel
<maco> so where do OOo patches get pushed to? OOo-proper or Go-OOo?
<persia> Ask ccheney :)
<persia> And we're still at 79 at 6:00 :(
 * persia needs to stop digging at hard ones, and hunt through for easy ones
<maco> persia: unsubscribe the reviewers team after marking patch-needswork?
<persia> maco: Please, and please give the patch submitter as *much* detail as you can about how to fix it.
<persia> I'm not sure we have a good model for what to do once the patches get fixed: maybe hint that they can resubscribe us.
<maco> persia: a comment has already done that
<persia> nigelbabu: When you get back: this is a case that deserves some thought: how to we recapture patches that needed work to ensure that they don't get lost.
<maco> persia: dont suppose a script could be written to run periodically that churns through all bugs tagged "patch-needswork" and check the activity log to see if a patch has been added since the tag was and if so, replace the patch-needswork with patch?
<maco> (no idea if lplib exposes enough info for that though)
<persia> That might work, but we'd need to find a way to put it in a workqueue.
<persia> Maybe have that script remove patch-needswork and subscribe the reviewers team again?
<ajmitch> oops, looks like I missed dholbach's session :)
<maco> ajmitch: its still going
<maco> he's doing a Q&A
<maco> and im learning more about this UDD stuff and how it makes everything ive been doing obsolete and wrong
 * ajmitch goes to read the backscroll
 * ajmitch needs to learn how to be a rock star 
<persia> maco: It's not obsolete and wrong.  I do nearly everything that way.  There are alternatives.
<maco> apparently i fail at humour this far past bedtime
<ajmitch> even though I've been using bze since 0.0.x, I'm still getting used to the Proper way of using it for packages
<ajmitch> s/bze/bzr/
 * persia isn't convinced there exists *the* proper way.
<persia> I've used it in at least 3 different ways, depending on the set of packages with which I was interacting.
<ajmitch> yeah, I've used it with having upstream+debian+integration branches
<ajmitch> that made for fun times
<persia> Hey gotunandan!
<gotunandan> hi persia
<persia> It's Patch Day! We're following https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow : just ask if you have any questions, or need an opinion or a hand.
<gotunandan> i do not know how useful I can be right now, since I am on a windows PC (at work :P )
<persia> Ah, yeah, that makes it tricky to test the patches :)
<gotunandan> Also I think I'll need to do some reading up on the entire packaging process, pretty keen on doing something at least in the maverick cycle !
<persia> I'd actually recommend against "reading up" too much.  It's easy to get stuck in circles of ever-more-complex documentation for specialised corner cases.
<persia> If you just want to do packaging work for Ubuntu, I'd suggest you'd do better to hang out in #ubuntu-motu, try to work on some of the MOTU TODO tasks, and ask questions whenever you get stuck (this will probably be *lots* at the beginning).  Folks will likely point you at specific, targeted, documentation that helps you understand the problem at hand, rather than you needing to learn everything first.
<gotunandan> oh, but its been a while since I last did some packaging, my ppa has been stale for a few months now :| Just need to refresh a bit, I guess
<persia> Even our most knowledgeable packagers don't pretend to know everything about packaging.
<gotunandan> right, thanks :)
<ajmitch> not even persia knows all :)
 * persia encounters unknown stuff *every day*
<persia> OK.  7:00 and we're down to 76.  I'll blame that on the recent -classroom session, but let's get back to Patch Day!
 * ajmitch hasn't been working on any for several hours 
 * imbrandon grabs the list-o-bugs
<persia> We're down to one page :)
<ajmitch> and some of the bugs have 2 tasks listed there
<persia> Hey etretyak!
<etretyak> persia, hi
<persia> We're following https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow and down to 75 bugs in our current worklist.  Jump in, grab one, and ask if you have questions.
<etretyak> ok.. let me see
<persia> Welcome ddecator :)
<ddecator> thanks persia =)
<ddecator> hopefully you guys can introduce me to what patch reviewing entails this weekend. is there a wiki page i can look over?
<persia> https://wiki.ubuntu.com/ReviewersTeam is probably a good place to start.
<persia> https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow is the core of what we do.
<ddecator> perfect, thanks
<persia> Hey zus!
<zus> persia, helllo
 * zus waves to persia
<persia> Did you change your mind, and are staying up to review a few patches, or just stopping by?
<persia> Ah, the latter, I think :(
<ddecator> how long does it take to review a patch?
<persia> Minutes to hours, depending on the complexity of the patch, etc.
<ddecator> if you got one that'd only take a few minutes, i can see about helping out real quick before i go to bed =)
<persia> Sometimes we get lucky, and the patch is submitted by upsteam, so it's just a quick test and see about getting into Ubuntu.
<persia> Sometimes we're unlucky, and the patch is confusing, does something subtle that's tricky to reproduce, and has an usptream with an irregular bug tracker with a complicated signup process.
<ddecator> i'll let you guys handle those for now..
<persia> Bug #527639 looks like it's not terrible.
<ubot3> Malone bug 527639 in boinc "boinc should use chrt instead of schedtool" [Wishlist,Triaged] https://launchpad.net/bugs/527639
<persia> Should be easy to test, and seek upstream comment.
<ddecator> so since it's not necessarily a bug to reproduce, i just get the software, see how it works, apply the patch, and make sure it doesn't break the functionality at all?
<ddecator> persia: ^
<persia> Basically, yeah.
<persia> Also, check some upstream docs on schedtool and chrt and make sure that it actually makes at least some sense (no reason to bother upstream if it's pointless).
<persia> I suspect it does make sense because without having thought about it previously, I have chrt on my system, and don't have schedtool, but that may be coincidence.
<ddecator> right, which seems to be the reasoning behind the suggested change
<persia> Indeed :)
<persia> You did ask for an easy one :)
<ddecator> alright, so i have some more questions about what i should do exactly, but i'm afraid that'll take up too much time and i've already stayed up later than i should have, so i'll return to this patch tomorrow and ask for some help in here =)
<persia> OK.
<ddecator> thanks for the help persia
<ddecator> g'night guys
<persia> Note that someone else might grab it first though, and you'll have to get a new one.
<ddecator> that's fine
<ddecator> i'll watch to see what the person did in that case
<persia> Hey RAOF.  We're almost done, but can always use a bit more on the last push :)
<persia> OK.  75 bugs.  3 hours.  It's a push, but  possible.  Now we just need a *heap* of reviewers in the eastern pacific :)
<persia> Hey alourie|work.
<persia> Still 75 at 8:00 :(
<nigelb> persia: how are we doing on the count?
<persia> Not wonderfully :(
<nigelb> breached 70s?
<persia> We're down to 75, but we've been holding there for a good while now.
<nigelb> ouch, was 79 when I left
<persia> So it's nice to have only one page of reports, but I think not many people still find it 5th May :)
<nigelb> well, patch day gets over in about 20 days and we can review what we did wrong
<nigelb> I have a couple of complaints with the workflow which I need to correct
<nigelb> I feel we should never unsubscribe ~ubuntu-reviewers unless we don't intent to review that patch at all
<nigelb> also, I'm thinking of defering a few packages to the server folks, the ones that are too hot to handle for us
<persia> Hrm?  80 minutes I thought.
<nigelb> 1100 UTC is when?
<persia> 78 minutes from now.
<nigelb> ok, my time calculation is just broken :)
<persia> So, my thought on unsubscription is that if we have already reviewed a bug, why do we need to stay subscribed?
<nigelb> also we need a way for people to say, I got this, the ~ubuntu-reviewers need not get into this bug
<nigelb> the unsub is because I'm giving other folks can option to say ^
<nigelb> so, all the sub'd bugs would be taken care of by us, and others would be taken care of someone else
<nigelb> great, now I have putty, my private key, but forgot to note down the ip adress and port to connect to :(
<persia> I don't think that's a big deal: if we bump into bugs like that, we can just unsub.  It's usually fairly easy to identify when someone has it, and it's not that hard to add our tags and unsub.
<persia> heh.
<nigelb> yes, so we'll make a policy that we wont take of bugs that we've unsub'd
<nigelb> so I'd rather have the others in the review queue.  anyway it wont show up in the query unless ready for re-review
<persia> How does "ready for re-review" work?
<persia> Especially for the patch-needswork case?
<nigelb> we leave instruction that once you feel the patch needs another review by us, please change the patch-needswork tag to patch tag
<persia> Oh right.
<persia> maco: ^^
<nigelb> i probably need to work on standard replies
<persia> heh
<nigelb> any other lessons from patch day?
<persia> 10:00 and still 75 bugs.  Over to nigelb!
<persia> We need to do better at determining what to do with Ubuntu-only packages.
<persia> When there's no real upstream, I'm not sure how much we can help.
<persia> Maybe that's just extending the blacklist a lot.
<nigelb> I'd vote to blacklist packages like eucalyptus
<nigelb> we'll just break their workflow
<persia> And stuff like apport/mountall/casper/ubiquity/etc. as well?
<nigelb> yep, especially stuff maintained by folks at canonical
<nigelb> they are being paid to do it, we're better off helping the packages that noone cares about
<persia> I disagree with that.  I don't see how it matters whether it's being maintained by folks at Canonical: I think it matters more whether it's being maintained *in* Ubuntu.
<persia> So, there's folks at Canonical who maintain a bundle of packages and do most of their uploads to Debian, etc.  They might use the package in Ubuntu, but ae normal upsteams in that they don't tend to use distribution-provided packages.
<nigelb> yeah, well, they tend to sort of coincide
<persia> And there's package in Ubuntu, like ubuntustudio-controls, that aren't maintained by folks at Canonical, but have no sensible separate upstream.
<nigelb> we ignore those is what I'm saying
<nigelb> the ones that are always uploaded to ubuntu
<persia> Sure, but I think we should focus on stuff where upstream maintains it in Ubuntu, rather than anything else.
<persia> whereas something like python-lazr.uri would work fine with our regular process.
<persia> (or maybe that wasn't the best example, but you get the idea)
<nigelb> its extremely subjective, we'e better off having a wiki page were folks can suggest the ones we can *potentially* ignore and then take a call
<persia> That sounds ideal: let's have a wiki page and invite developers who maintain their packages *in Ubuntu* and don't want us pushing patches upstream to add their packages there.
<persia> That makes it opt-in on a per-developer/per-package basis.
<persia> And nicely avoids all the social discussions :9
<persia> :) !
<nigelb> yes, better than them coming screaming at us
<nigelb> ok, so graphs, changes to workflow, standard replies, and page for developers to opt-out
<persia> Well, if we have a wiki page, and we announce it to ubuntu-devel@, then if folks come screaming, we can point at the wiki page and the email, and ask them why they don't read their mail :)
<nigelb> exactly!
<nigelb> Anything else hit you we're doing wrong?
<nigelb> Did we advertise too less about patch day? :/
<persia> I think we did fairly well.
<persia> 110+ patches reviewed.
<nigelb> It would be very intersting to see the patch review mailing list, especially the moderation to see how many people participated
<nigelb> all the bug mails would be stuck in moderation.  I have to ask brian to give me a tar or something of all the mails over last 2 days
<persia> I think we also need to work on integration with bugsquad more.
<persia> I saw someone in bugsquad suggest subscribing us and adding the patch tag as the way to triage a bug with a patch.
<nigelb> woot, yes it is :)
<persia> But I'd rather be more integrated, so that folks upstreaming bugs know about our tags, and we make sure we do the right upstreaming stuff when we forward our patches.
<nigelb> raise it at the next bug squad meeting?
<nigelb> its after UDS anyway
<persia> Sounds like a good plan.
<nigelb> during UDS you can say how successful Patch day was ;)
<persia> and make sure the upsteaming docs point to our docs about tags when also sharing patches and make sure our docs point at the upstreaming docs as best practice when opening upstream reports, etc.
<nigelb> our docs point to upstream docs
<nigelb> *upstreaming
<persia> Sure, but let's make sure we *preserve* that as we update our docs :)
<nigelb> yes, the docs need extensive revision, including how to test
<persia> We're an interesting mix of triagers and developers (and folks who are both), and I'd like to not end up with too much of a separate identity.
<persia> Patch review should be something people do, not something people are.
<nigelb> did I tell you the statistic I had come up with?
<nigelb> 1800 bugs with patches attached, out if which 1500 will be in our queue if there were no date thingy.  If all the members of ~ubuntu-dev reviewed 10 bugs, we'd be done!
<nigelb> there were 153 members of ~ubuntu-dev when I last checked
<nigelb> if everything comes together, patch review, adopt-an-upstream, bug triage, it would be the most awesomest!
<persia> Yeah.  It's not hard to review all the patches.  Folks just aren't doing it.  That's why we needed this initiative.
<nigelb> Yep.  I'm deeply saddened by that.
<nigelb> But, also happy that in 1 month, we could get going so fast.
<nigelb> This cycle, I'd like to explore the possibility of us being the new starting point for development, though I'd advocate uploads to debian than Ubuntu to reduce the delta.
<persia> I don't think any model that involves the starting point for development is good.
<persia> I'd rather consider us *a* starting point.
<nigelb> Well, yeah *a* starting point, especially to budding triagers
<nigelb> People who are well versed with bugs and want to start thinking of packaging stuff
<persia> And I think that work in this team is a close match to a lot of MOTU work, so it makes a good "next step" for bug control folks vaguely wanting to do more development, but without any close association with one of the development teams (e.g. desktop, server, kubuntu, mythbuntu, etc.)
<nigelb> yep, lost folks like me ;)
<persia> Right.  I think we're thinking the same, except for the "a"/"the" bit :)
<persia> I don't like to think we're lost, so much as we're more interested in fussing with random stuff than focusing on anything specific.
<nigelb> yea, I agree with the 'a' too
 * persia tends to focus first on anything that is irritating when using Ubuntu installs, and then on various unloved pacakges.
<persia> At least, for me, if someone is caring for a package, they tend to do a good enough job that I'll end up being lazy, rather than fixing it.  If nobody else is watching, then I'm more likely to be annoyed and just fix it.
<nigelb> Desktop team likes us taking care of patches, so far they're happy that we're pointing out stuff that work
<nigelb> But I'd defer mozilla stuff to somene from the team since they take good care of them
<nigelb> Also, most of the patches tend to turn up in unmaintained stuff since no one maintaines those pacakgse
<nigelb> People get annoyed and fix the bug.
<nigelb> And we ignore them.
<nigelb> We're down to 74, I guess you're reviewing.
<persia> I must run: good luck with the end of the day.  I think we made great progress, regardless of the counts, just from the number of folk who came by the channel and read the docs, and had some practice doing it.
<nigelb> persia: I'm stepping out for some chores too. :)
<nigelb> persia: shall I delcare patch day officially over?
<nigelb> another 15 mins to go, but I have to run
<persia> If you have to run, unless you can get someone else, yeah.
<persia> 111 bugs done!
<persia> Actually more, because we got some new ones (the count went up a couple times)
<nigelb> Patch Day is officially over.  Thank you Review Leads for your help.  Those who reviewed patches, thank you for your time.
<nigelb> We have reviewed 111 bugs in the last 50 hours!
<persia> 49 :)
<nigelb> 48-3/4 ;)
<persia> We hit 61% of our target queue.
<nigelb> Which is really really good news
<persia> Which isn't bad for a first time.
<nigelb> now, I think we can move that date 1 month back
<nigelb> and plan for regular patch days
<nigelb> no wait, scratch regular patch days
<persia> Every month?
<persia> Yeah, let's not have them for a while.
<nigelb> we need something to encourage every day review, like 5-a-day
<persia> Let's have sporadic patch days on an as-needed basis until we get a feel for how the team works.
<persia> and if enough folks want to have a special Patch Day! we can do that.
<nigelb> yes, when we get dangeoursly high, for now lets just keep things in 2 digits :)
<persia> That makes sense to me, but let's not worry so much about next week, as lots of folks will be paying attention to UDS.
<persia> With luck, we won't get so many patches, but I expect a bit of backlog :)
<nigelb> persia: yes, and do tell them about the 10 patch per head thing and the 111 that me manged :)
<nigelb> *we
<persia> Really, UDS doesn't work that way: there's no good way to do announcements.
<nigelb> plenary?
 * persia is *not* going to try to schedule a plenary about Patch Day
<nigelb> lol, ok
<nigelb> just mention that in the session
<persia> Best is just to send mail to the developer and bugsquad mailing lists, saying what was done.
<nigelb> Yes, that's a good idea
<persia> That ends up getting mirrored all over the place
<nigelb> The fridge can re-post *that* one
<persia> Anyway, really have to go :)
<nigelb> ok, ciao
<vish> aw.. i did probably only around 5 :(
<maco> <persia> We need to do better at determining what to do with Ubuntu-only packages. <--- subscribe sponsors?
<yofel> would be fine, but only after we convert it into a debdiff
<yofel> (IMHO)
<yofel> I saw bugs where the sponsors were subscribed, didn't find a debdiff, unsubscribed themselved and subscribed us
<maco> which they're not supposed to do
<maco> the debdiffs-only stuff was supposed to have gone out a year or two ago
<yofel> hm, I didn't check the dates on the posts
<vish> maco: recent bugs too its being done
<yofel> well, packaging the patch included reviewing it so it makes sense in some way
<yofel> *includes
<maco> "check it before you upload" has always been part of the sponsor's job
<maco> even if it's a debdiff, they're still supposed to check it out!
<yofel> true
<vish> hrm , if the patch has been forwarded upstream do we unsubscribe te review team?
<vish> the*
<yofel> is says so on the workflow, you're supposed to subscribe yourself and follow the bug after that
<vish> yofel: Bug #40872 , nigel has subscribed himself, i think we can remove the review team..
<ubot3> Malone bug 40872 in nautilus "Desktop icons are allowed to overlap" [Unknown,Confirmed] https://launchpad.net/bugs/40872
<yofel> true, work is done
<persia> So, patches for ubuntu-local stuff fals into an annoying gap.
<persia> Sponsors *aren't* supposed to upload anything that isn't a ready candidate, and *are* supposed to be all sorts of picky to help train nascent developers.
<persia> But we're not even especially focused on getting stuff into Ubuntu.
<persia> The thought was to blacklist the Ubuntu-local stuff from the script that fills the review queue, and then expect whoever maintains the package to process the bugs once in a while.
<persia> (where "whoever maintains" might be some random Ubuntu developer passing by, depending)
<persia> That said, there's no reason that any of us *can't* turn a patch into an upload candidate in any of several ways, but that it's not the main goal of the team.
<yofel> hm, about bug 546032 - I did use reportbug a few times already, but never supplied patches, and I don't get how submittodebian works, can I just use reportbug with the patch tag and supply links to the patches in the bug description?
<ubot3> Malone bug 546032 in tcsh "[PATCH] tcsh-6.14.00-astron $COLUMNS $LINES not set" [Undecided,New] https://launchpad.net/bugs/546032
<persia> I usually attach the patch in an email to the BTS.
<persia> I'm not sure how reportbug does it.
<yofel> well, reportbug is a cli app that creates a mail, but you're right, just sending a mail directly would be easier I guess
<persia> yofel: reportbug has a -A option that lets you attach something, so you could use that.
<yofel> ah, you're right, thanks
<persia> Just be sure to add the patch tag if you sdo.
<persia> manpages are wonderful :)
<yofel> yep, I did check it, too fast it seems :P
<nigelbabu> maco: UUD can be taken at UDW
<nigelbabu> err UDD
<hyperair> nigelbabu: so how did patch day go overall?
<nigelbabu> hyperair: 111 patches reviewed
<hyperair> woo
<hyperair> that's a lot
<hyperair> it's now down to one page \o/
<nigelbabu> yes, thanks a lot for the tme that the review leads put in
<nigelbabu> I intend to write a mail, now sleep time
<vish> nigelbabu: hey ,any reason we you've left the team still subscribed to  Bug #40872
<ubot3> Malone bug 40872 in nautilus "Desktop icons are allowed to overlap" [Unknown,Confirmed] https://launchpad.net/bugs/40872
<nigelbabu> vish: Its reviewed, see tags
<nigelbabu> the review team will not be unsub'd ever unless they dont want us playing with the bug
<nigelbabu> I'll change the docs as soon as I'm sane and conscious
<vish> nigelbabu: yup ,the docs wasnt clear... hence, was wondering if the team needs to be un-sub'd there..
 * persia has been unsubbing from everywhere, and wonders why we bother to have sub/unsub at all if we're not unsubbing to drop from the workqueue
 * hyperair did the same as persia
<nigelbabu> vish: I realized the hole in the docs only today.  Its my mistake
<nigelbabu> Just to make it clear.  Do *not* unsub reviewers unless they dont want us poking in
<nigelbabu> persia can explain further on that or you can read scroll back
<hyperair> =\ i don't even remember which bugs i unsubbed reviewers from
<nigelbabu> we talked about it 2 hours back
<nigelbabu> hyperair: dont worry, we can find with tgas :)
<hyperair> heh okay
<nigelbabu> I'll do that next week, though I may have to run a huge LP query through api
<nigelbabu> persia: can follow up with lool about the MIR? I need sleep and rest
<persia> I can't explain, because I don't see the point (but I'm sure nigelbabu will explain better later)
<persia> Which MIR?
<nigelbabu> bug 525512
<ubot3> Malone bug 525512 in libtime-modules-perl "[MIR] libtime-modules-perl" [Undecided,New] https://launchpad.net/bugs/525512
<nigelbabu> but 525395 is blocked due to this
<yofel> so instead of usubbing reviewers remove the patch tag? or just add the tags?
 * persia doesn't like MIRs are part of not liking components, but isn't prepared to ignore components completely yet
<nigelbabu> yofel: just change the tag according to situation
<persia> nigelbabu: And the query already hides stuff with the right tags?
<nigelbabu> persia: yes it does
<nigelbabu> the unsub was part of workflow when I didn't know that
<nigelbabu> brian explained it to me that day, that meeeting we had
<persia> OK.  I'm not sure there's any benefit to any of subscription/unsubscription/even having a team in LP if we're not actually using it.
<yofel> k, so change the tag (and leave only one) and leave team subscribed, right?
<nigelbabu> yofel: yes
<yofel> ok
<nigelbabu> persia: having the team sub'd gives option to others not to have us meddle
<yofel> I'll try to fix the bugs I still find in my inbox later
<persia> How?
<hyperair> nigelbabu: but other people can't unsub us.
<persia> But explain it to be when you've slept.
<persia> I'm sure I'll disagree then too, but we can have a productive debate :)
<nigelbabu> persia: when there is a bug a and there is a very responsible person taking care of it
<vish>  IMO , unsubscribe if someone takes up the bug..
<nigelbabu> vish: no
<hyperair> launchpad api again \o/
<hyperair> nigelbabu: go sleep =p
<nigelbabu> what if that person "gets hit by a bus"
<nigelbabu> hyperair: good idea
<nigelbabu> I should
<hyperair> =)
<vish> nigelbabu: i meant , if forwarded upstream..  , but not very sure the current flow is good though
<persia> nigelbabu: Do.  I'm fully prepared to debate this with you another day.
<hyperair> count me in.
<vish> lol!
<yofel> me too
<nigelbabu> vish: we still want it on the list, later, sleep is overtaking me
<persia> nigelbabu: And I think you've been pinging lool sufficiently for 525512: I'll pay attention and say something if necessary whist you sleep, but it may just be a matter of time.
<nigelbabu> persia: most probably, only if he asks something you feel I wont be able to answer :)
<nigelbabu> persia: and I dont want to wait for 24 hours to finish a conversation ;)
 * nigelbabu goes before someone kicks me out
<persia> I think it's 99% a matter of waiting for him to have time, which means it's probably not going to happen until post-UDS.
<nigelbabu> im just reminding, btw vish had you assigned a bug to me? I vaguely remember a mail
<yofel> hm, a patch attached and issue already fixed upsteam in a different way would be patch-rejected-upstream?
<yofel> bug 542185
<ubot3> Malone bug 542185 in qt4-x11 "holdingnuts GUI badly affected by a bug in Qt 4.6.2" [Medium,Triaged] https://launchpad.net/bugs/542185
 * persia looks
<vish> nigelbabu: the cheese bug?
<vish> nigelbabu: wasnt that what we discussed the other day?
<yofel> upstream patch: http://qt.gitorious.org/+kde-developers/qt/kde-qt/commit/1ab5feb6260589f254ed209816cb67dbe9d3e4a5
<persia> Yeah, that'd be patch-rejected-upstream, but it's worth adding a comment that this tag is used to denote the case where a patch doesn't match upstream changes perfectly, so that we know it has to be an Ubuntu-local adjustment, etc.
<yofel> ok, thanks for confirming
<persia> I'm not certain that all patch authors would understand this use of "rejected" (which isn't quite right) without explanation.
<yofel> indeed
<persia> But I'm not sure what other tags correctly toss the bug into the right "bucket": specifically the set of stuff that needs a developer to apply in Ubuntu directly.
<vish> persia: i see one problem though , once we unsubscribe the team , the person who takes over must fully respond to the bug .. or we need to draw a line where the reviewer work ends.. if the bug patch is redone after 2-3 months what is the procedure then? if the person subscribed has gotten busy and is not looking at bugmail?  who's task is it to check the patch then?
<persia> vish: I don't think whether the team is subscribed or not makes any difference in that case.
<persia> I think we'd do better to define a set of states in our patch management workflow, and then focus on moving patches between these states in various ways.
<persia> subscription/unsubscription is one tool that could help with that, because it lets us set a match criteria for LP queries (and in a way that *dosen't* send bugmail).
<persia> But just because the team is subscribed doesn't mean anyone will ever look at the bug.
<vish> persia: yup no bug mail , but in that case , having the team subscribed might ensure the bug gets a second look ,... but still the current workflow isnt perfect though , this makes
<vish> s/this makes/  /
<persia> do a search sometime on all the bugs assigned to MOTU.  Every single one of those is wrong, and nobody has ever used that query to find work to do.
<persia> Why would it get a second look?  If it doesn't show in the queries on the reviewing guide page, it's not likely to be looked at, regardless of anything else.
<vish> persia: if the team is subscribed it could be looked again , but the tags would be misleading.. which is kinda wrong , what we need is the re-tagging to work properly and automatically ,once a new patch is submitted ,the old patch must be auto removed and subscribing the team then would probably work
<vish> s/old patch/old tag/
<persia> vish: *why* would it be looked at again?  Who would look at it?
<yofel> is the mail that the review team gets as a launchpad group sent somewhere or to /dev/null ?
<persia> And how would the result differ from e.g. a query againt the "patch" tag?
<vish> right..
<persia> yofel: It goes to an LP mailing list that is subscribers-only, so most stuff ends up in a moderation queue, and is dropped summarily.
<persia> vish: My point is not that the current system is correct.  My point is that there's no inherent value to subscription, unless subscription is used to define a query that is used as a workqueue.
<vish> +1
<persia> Well, and also that it has no more or less value than any other change we make to bugs to define a workqueue.
<yofel> ah, if there was some way to access it I think it would make sense to leave the team subscribed, but from my point of view I would vote to unsubscribe the team currently
<vish> persia: currently the workflow is kinda what anyone can do , there is no need for a specific team :s
<yofel> +1
<persia> Well, unless we use subscription/unsubscription as a way to manage workqueues.  We currently do, in that we only have the team subscribed to a subset of the available bugs, so as to focus on quick response to current patches, rather than too much on older patches.
<yofel> only team members can unsubcribe the team, which means that if we don't require that we don't really get to review newcomer work as they have no reason to contact us
<persia> I'd say that the vast majority of the patches we reviewed during patch day were submitted in the last couple months, which is good.  If a patch has already sat around for a year, we already look bad, and it's not worth missing new ones to try to clean them up until we're ahead of ourselves with the new ones.
<persia> yofel: Indeed, which is one of the reasons I *like* having unsubscription be part of the workflow: it encourages a member of the team to review all work by non-members until someone shows they know what they are doing, and can be made a member.
<persia> (as our current requirements for membership are basically: someone says "Yeah, this person is good at it).
<yofel> yeah, and about an hour to fulfill the bugsquad requirements
<persia> and a week to get approved :)
<yofel> unless somone doesn't use the desktop bugs team as a loophole yes
<yofel> as that gives you an indirect membership
<persia> There are lots of loopholes :)  But yeah.
<persia> The point of the requirement is basically that we didn't want to have to explain basic bug triage stuff also in the reviewers docs.
<persia> Oh, and that most of the tasks end up being very similar to triage tasks, so it's helpful to have that background (in any of the *many* ways in which one can get it).
<yofel> true
#ubuntu-reviews 2010-05-07
<nhandler> http://blog.bofh.it/debian/id_375 :(
<persia> That's the next hurdle.
<persia> First we need to get on top of the patches Ubuntu is completely ignoring.
<persia> Then we can apply our skills to the patches that Ubuntu is hoarding.
<nigelbabu> just an announcement, we're at 69 bugs.  can we make it 0 before UDS?
<ddecator> alright, i'm thinking of trying to review a patch. is anyone here in case i run into any trouble?
<dholbach> good morning
<dholbach> nigelbabu: so... what did we get out of the patch day? how did it pan out? :)
<nigelbabu> dholbach: 116 patches reviewed
<nigelbabu> dholbach: I'll send out a mail and blog post today
<nigelbabu> persia: you about?
<nigelbabu> we need to have that debate :D
<dholbach> nice
<nigelbabu> dholbach: in belgium?
<dholbach> nope, I'll get there on sunday
<nigelbabu> ah, ok
<dholbach> I'm sorting out a few smaller things, then get to planning my UOW session
<nigelbabu> oh, yeah, the first 2 hours :)
<nigelbabu> dholbach: got a minute for me? can you look at the latest ubuntu-review-overview code and see if things look okay?
<dholbach> nigelbabu: link? :)
<nigelbabu> http://bazaar.launchpad.net/~nigelbabu/ubuntu-review-overview/trunk/annotate/head%3A/patch-overview.py
<dholbach> nigelbabu: will take a look
<nigelbabu> thank you :)
<nigelbabu> ddecator: you wanted to get started with review?
<nigelbabu> cyphermox: /ws 28
<nigelbabu> grr
<cyphermox> moo?
<nigelbabu> sorry :)
<nigelbabu> anyway since I pinged you by mistake...
<nigelbabu> Thanks for being a review lead, we managed to get the count down to 69 unreviewed bugs now
<nigelbabu> cyphermox: a total of 116 bugs reviewed :)
<cyphermox> didn't really do much, but np :) it's great that things are going well
<nigelbabu> :)
<dholbach> nigelbabu: just small changes: http://people.canonical.com/~dholbach/patch
<dholbach> fixed imports
<dholbach> fixed the filename
<dholbach> etc
<nigelbabu> thank you :)
<nigelbabu> dholbach: why is the tasks line removed?
<dholbach> nigelbabu: because it's called twice
<dholbach> nigelbabu: and the second time "tasks" is not used again
<nigelbabu> dholbach: oh yeah, grr why didn't I see that one
<dholbach> no big deal :)
<nigelbabu> it takes a good deal of time to run, planning to run it overnight
 * nigelbabu is making graphs
<nigelbabu> persia: I have holes in the data, we didn't post hourly :(, neither you nor me
<persia> nigelbabu: I suspect there wasn't that much variation for many of the gaps, but extrapolate where you can :)
<nigelbabu> persia: I have an unpretty graph
<nigelbabu> I dunno how to make it pretty, suggestions welcome
<nigelbabu> http://people.ubuntu.com/~nigelbabu/patch-day.jpg
<nigelbabu> persia: ^
<hyperair> nigelbabu: now differentiate the graph with respect to time and make a new one =p
<nigelbabu> hyperair: it is differentiated with time
<hyperair> what's the timezone of the times in the graph?
<nigelbabu> UTC
<hyperair> nigelbabu: no, i mean dy/dx
<hyperair> nigelbabu: which would get you a graph of the gradient per time
<nigelbabu> hyperair: oh, that
<nigelbabu> ok, prettier now, http://people.ubuntu.com/~nigelbabu/patch-day-2.jpg
<nigelbabu> persia, dholbach, hyperair: ^
<nigelbabu> no, I didn't do the dy/dx
<hyperair> haha
<hyperair> cool
<hyperair> what did you use to draw the graph anyway?
<nigelbabu> open office
<nigelbabu> it sucks, I know
<nigelbabu> oh no, the graph is statistically wrong
<nigelbabu> hyperair:can you look at the second graph...
<nigelbabu> you'd notice that I had some gaps in time, is that okay?
<nigelbabu> i mean mathematically
<hyperair> nigelbabu: there are gaps?
<hyperair> i didn't notice
<hyperair> and i didn't know openoffice could make graphs
<yofel> I don't mind the gaps, if the graph wouldn't look like it's bending space and time...
<nigelbabu> hyperair: how else do you make graphs
<hyperair> nigelbabu: gnuplot.
<hyperair> nigelbabu: they look quite bad though
<nigelbabu> yofel: the distance between 1 hour and 3 hours look the same
<nigelbabu> hyperair: they look bad now? or on gnuplot?
<hyperair> nigelbabu: gnuplot.
<hyperair> nigelbabu: let me look for a graph i did sometime back..
<hyperair> http://dl.dropbox.com/u/169656/banshee-memusage.png
<hyperair> nigelbabu: ^
<nigelbabu> hyperair: I <3 it!
<hyperair> nigelbabu: !!
<hyperair> nigelbabu: but the font hinting is not really good.
<hyperair> nigelbabu: well you could use plotdrop, it's fairly easy to use.
<hyperair> it's a drag-drop gtk+ ui for gnuplot
<nigelbabu> hyperair: yuck, only command line?
<hyperair> nigelbabu: unfortunately so.
<hyperair> nigelbabu: but like i said, plotdrop's pretty good. i made that graph using plotdrop.
<nigelbabu> double yuck
<nigelbabu> updating, cant apt-get for another 15 mins
<hyperair> heh
<nigelbabu> hyperair: will the current graph do for basic stuff?
<hyperair> nigelbabu: i think it's fine really
 * nigelbabu needs to move to next item on "things to do"
<nigelbabu> ok, ty
<nigelbabu> http://pad.ubuntu-uk.org/aTor4hFZXZ
<nigelbabu> I'm writing a mail to devel, anyone care to help me edit the thing more finer?
<dholbach> nigelbabu: NICE
<nigelbabu> dholbach: :)
<popey> yup, good to me
<nigelbabu> thanks popey :)
<popey> np, anytime
<nigelbabu> persia: new plan, as soon as mails from the mailing list hits of new patches, attack them, so we keep the count to down
<nigelbabu> yesterday and today, there were 2 that were supposed to be ignored but one task was not a blacklist, so we eneded up getting sub'd
<nigelbabu> I'm doing some wok on standard replies.  If anyone would like to create new ones or correct the ones I have there, please go ahead
<nigelbabu> https://wiki.ubuntu.com/ReviewersTeam/StandardReplies
<nigelbabu> I'm sure Patch Day might have given some ideas of what to write
<ddecator> nigelbabu: yah. not sure how much i can help, but i'm interested in learning how the process works so i can do it if i have extra time or a need to review one at some point
<yofel> hm, I didn't read the whole page in a while, but I just noticed that https://wiki.ubuntu.com/Bugs/Patches doesn't mention the review team at all...
#ubuntu-reviews 2010-05-08
<nigelbabu> we/re at 67 bugs of now, just fyi
<maco> hi
<CloudMonkee> hi
<CloudMonkee> how do i get started?
<maco> review guide: https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide
#ubuntu-reviews 2010-05-09
<nigelbabu> maco ty for the advertisement :)
<maco> nigelbabu: in #ubuntu ?
<nigelbabu> no up ^
<maco> cloudmonkee?
<nigelbabu> yep
<maco> they're someone who was asking in #ubuntu why lucid sucks and i said because not enough people test early alphas and not enough people fix the bugs they find
<nigelbabu> haha
<maco> so they asked how they could help fix that
<maco> they know java and c++ and i told them about patch review, triaging, and alpha testing
<maco> oh and bitesize bugs
<nigelbabu> so they came here :)
<maco> yeah. i was helping them in pm with how to get set up on launchpad and how to use it
<maco> because reading the review guide they didnt know how to tag bugs or subscribe to them or anything
<nigelbabu> then should have asked to do bug squad stuff for 2 weeks and then come to review
<maco> they can read code...seemed this was a good place
<maco> but i did explain a bit about the sort of debugging thats involved in triaging
<nigelbabu> yeah, but fokls get lost about upstreaming sometimes, so we send them to do bug triage
<nigelbabu> thats why bug control folks can get in quite easily
<maco> well hopefully theyll be back and we can do a bit of mentoring
<nigelbabu> yeah :)
<nigelbabu> But thanks again :)
<ddecator> i still need to learn this process..
<nigelbabu> did you see the pretty graphs for patch day?
<nigelbabu> ddecator: did you go through the review guide?
<maco> nigelbabu: no i did not
<nigelbabu> maco: it should be in my mail to -devel, hold on, let me hunt down the link
<ddecator> nigelbabu: not in detail, haha. i've been meaning to do it this weekend. i need to work on a software center wiki page tonight so idk if i'll get to it tonight or not, but if not tonight i'll try for tomorrow. i skimmed it and it seems pretty straight-forward, but i'm sure i'll run into questions when i actually review my first patch
<nigelbabu> ddecator: just ask here, someone will reply, at least in scrollback
<nigelbabu> maco: http://people.ubuntu.com/~nigelbabu/patch-day-2.jpg
<ddecator> nigelbabu: i plan on it =)
<nigelbabu> maco: we sorta got lazy towards the last few hours
<maco> nigelbabu: thats a pretty good decrease!
<nigelbabu> maco: oh yes!
<nigelbabu> we're now at one page consistently
<maco> yay :)
<nigelbabu> maco: can make head or tail of this bug? bug 525395
<ubot3> Malone bug 525395 in backuppc "Missing dependency to libtime-modules-perl" [Undecided,Confirmed] https://launchpad.net/bugs/525395
<maco> nigelbabu: not til after midnight
<maco> i have a paper due at midnight
<nigelbabu> at midnight?
<maco> thats 87 minutes
<maco> yes, by email
<nigelbabu> lol, ok :)
<nigelbabu> maco: get off IRC!
<maco> nigelbabu: you pinged me!
 * nigelbabu bribes nhandler to k-line maco
<maco> only 2 pages left :)
<nigelbabu> thats not much :)
<nhandler> nigelbabu: No chance ;)
<nigelbabu> nhandler: hahaha
<nigelbabu> nhandler: can you put https://lists.ubuntu.com/archives/ubuntu-devel/2010-May/030748.html on the fridge?
<ddecator> oh, i remember what my noob question is. i'm assuming there is a way to apply the patches we review to the package instead of having to get the source and rebuild the package with the patch. how is that done?
<nigelbabu> ddecator: wrong assumption
<ddecator> dang
<ddecator> i was hopeful =p
<nigelbabu> ddecator: if you can read the code and make out if it works, you don't have to rebuild
<ddecator> didn't know how that would work though..
<nigelbabu> or you can ask to forward upstream if sure the patch is working
<ddecator> ah, ok. that'll be good practice to get me familiar with code then, haha. i don't have time to work on reviewing anything tonight, but at least now i know what to do for when i do finally get around to reviewing a patch..
<ddecator> thanks nigelbabu
<nigelbabu> ddecator: no problem :)
<nigelbabu> vish: got there ?
<vish> nigelbabu: wooh! UDS baby :D
<nigelbabu> vish: awesome!
<nigelbabu> vish: just 2 folks from here?
<vish> nigelbabu: just got here havent met all yet ;)
<nigelbabu> vish: cool!
<nigelbabu> nhandler: did you see my ping earlier re: fridge?
<nhandler> nigelbabu: Yeah, but it will need to wait until later. The family is coming over in under an hour for Mother's Day. You can poke someone in -news to look into it
<nigelbabu> nhandler: okay :)
<nigelbabu> qense: whom are you rooming with/
<qense> nigelbabu: Sarge
<qense> Don't know him, but seems a nice guy.
<nigelbabu> qense: nice :)
