#ubuntu-reviews 2010-04-19
<nigelb> I'll be talking to dholbach later today to make a list of things-to-do before Patch Day.
<nigelb> persia, due to the overwhelming lack of participation for review leads, I guess we'll both have to fill up the remaining hours :/
<persia> Fine by me :)
<nigelb> I'll make a last ditch recruitment effort on the last week of the month
<nigelb> if that doesn't work, bunk work, and live in front of the computer for 49 hours
<ajmitch> nigelb: that sounds like a fun option, be sure to have plenty of caffeine on hand
<nigelb> ajmitch, that was just an exaggeration.  I'll probably do only 8 hours at a time
<ajmitch> 8 hours on, sleep for 1 hour, back to the computer?
<nigelb> ajmitch, persia will be around too :)
 * ajmitch would help out if he knew what he was doing :)
<nigelb> oh yaay!
<nigelb> you need to know https://wiki.ubuntu.com/ReviewersTeam/GettingInvolved
<nigelb> you need to know how bug (and patch) upstreaming and ubuntu development (making debdiff, etc)
<nigelb> If you do, please sign up https://wiki.ubuntu.com/PatchDay
<ajmitch> yeah, it's the more recent things like working with bzr branches that I need to read up on
<ajmitch> it'd be over a thursday/friday for me
 * ajmitch wonders if someone will make up some greasemonkey scripts for handling these tags
<ajmitch> anyway, must go out for lunch, back soon
<dholbach> good morning
<nigelb> dholbach, in another 1.5 hours?
<ibuclaw> hey nigelb - what's up?
<nigelb> heya ibuclaw :)
<hyperair> 1.5h? what's going on?
<nigelb> hyperair, call
<hyperair> nigelb: call?
<nigelb> hyperair, yeah
 * hyperair doesn't understand
<nigelb> call, skype, talk
<hyperair> oh that
<ibuclaw> nigelb, ooh, fun times
 * ibuclaw is on the pcmanfm changelog yay!
<nigelb> ibuclaw, oooh
<ibuclaw> https://launchpad.net/ubuntu/+source/pcmanfm/0.5.2+svn20091029-1ubuntu3
<ibuclaw> not sure if it is in the main repos yet.
<nigelb> ibuclaw, http://changelogs.ubuntu.com/changelogs/pool/universe/p/pcmanfm/pcmanfm_0.5.2+svn20091029-1ubuntu3/changelog
<nigelb> Iain BucÅaw?
<ibuclaw> yepo =)
<ibuclaw> shame that one polish character isn't ascii
<nigelb> heh
<ibuclaw> have been using just plain 'Buclaw' for the updates I push for gdc
<ibuclaw> nigelb, http://changelogs.ubuntu.com/changelogs/pool/universe/g/gdc-4.3/gdc-4.3_1.046-4.3.4-3ubuntu1/changelog
<nigelb> w00t w00t lots of gdc entries :)
<ibuclaw> lots of work have been put into it. =)
<ibuclaw> nigelb, afterall ... I *am* the maintainer of the package.
<nigelb> 0_0
<ibuclaw> nigelb, http://packages.qa.debian.org/g/gdc-4.3.html
<\vish> heya , who's up for making a depdiff of this > http://bugzilla-attachments.gnome.org/attachment.cgi?id=136114
<\vish> its for a bug in the review list for Bug #111939
<ubot3> Malone bug 111939 in metacity "Not possible to alt-tab during a drag-and-drop operation" [Unknown,Confirmed] https://launchpad.net/bugs/111939
<nigelb> ibuclaw, wow :)
<nigelb> \vish, I can make a debdiff (I made once) can test?
 * nigelb did ask \vish to test some time back too!
<\vish> nigelb:  test ? how?
<nigelb> \vish, I'll push it onto a ppa and you have to update your metacity to that one
<ibuclaw> nigelb, don't ask how it happened ... I just asked nhandler and he suggested that I email doko about it. One thing led to another and he is now sponsoring me (or keeping a watchful eye, I'm not sure which)
<\vish> ah righto..
<nigelb> ibuclaw, its so totally totally cool :)
<nigelb> \vish, 20 mins tops
<\vish> bah everything is a bit of a mess in my system , there is a memory swap leak and i'm not able to do things :s
<\vish> nigelb: neat
<dholbach> nigelb: yep
<nigelb> dholbach, :)
<nhandler> ibuclaw: I'm glad to see that worked out for you
<nigelb> bdrung, thank you :)
<nigelb> re: patch day
<bdrung> you're welcome :)
<\vish> nigelbabu: hmm , i think bdrung had commented for a debdiff a long time ... we[I] could have done that a long time ago :s
<\vish> done the testing i mean ;p
<bdrung> \vish: which bug?
<\vish> bdmurray:  Bug #111939
<ubot3> Malone bug 111939 in metacity "Not possible to alt-tab during a drag-and-drop operation" [Unknown,Confirmed] https://launchpad.net/bugs/111939
<\vish> oops bdrung ^
<\vish> bdrung: seems nigelbabu had the debdiff done a while back and was just waiting for testing
<bdrung> oh
<nigelbabu> \vish, I did a debdiff some time back
<nigelbabu> but the package got updated
<nigelbabu> vish, thank you.  the \ was getting tough
<vish> nigelbabu: damn! will change back ;p
<vish> some problem with nm , keeps dropping my signal :s
<nigelbabu> its going to rain cats and dogs out here.  I hope power doesn't go out
<nigelbabu> vish, do you have FFE for this?
<vish> nigelbabu: i dont think we need an FFE for that , probably a stable release update will do
<nigelbabu> vish, we do, its not a bug fix
<vish> nigelbabu: i would consider it a bug though.. ;)
<vish> nigelbabu: anyway , irrespective of when it is getting fixed , we need a debdiff ;)
<nigelbabu> true.  getting
<nigelbabu> that was a productive talk :)
<vish> ^ cjohnston in a timemachine  ;p ?
<cjohnston> lol
<cjohnston> setting it up so its ready
<vish> cjohnston: you are at the hotel now getting it ready or.. just setting the nick?
<cjohnston> just the nick...
<cjohnston> I'm in ~50 channels on this connection.. so im setting up another irssi for uds
<cjohnston> make it a little easier
<cjohnston> im trying to figure out how i set this one up tho to match it.. easier said than done
<nigelbabu> vish, built on ppa.  pleaes test and let me know
<vish> hmm , let me restart session
 * vish brb
<nigelbabu> vish, works?
<vish> nigelbabu: oddly no :(  did it work for you on karmic?
<nigelbabu> I didn't test on karmic
<vish> i still can alt+tab while dragging
<vish> cant*
<nigelbabu> strange
<nigelbabu> sure you have the PPA version installed?
<vish> nigelbabu: it was only metacity and metacity common right?
<nigelbabu> yeah
<vish> hmm , wait there is libmetacity-private0 , installed that one too , let me try a session restart
<vish> nigelbabu: no go :(
<nigelbabu> aw :(
<vish> odd that mclasen mentions it works perfectly in fedora :s
<nigelbabu> yeah, extremely :)
<vish> heh , lets blame sabdfl on this one too ;p
<nigelbabu> lol
<vish> nigelbabu: check if it works in karmic..
<nigelbabu> vish, checking
<keffie_jayx> hey nigelbabu, just read dholbach post
 * vish brb
<nigelbabu> keffie_jayx, great, so you want to help us reviewing and also translating right?
<keffie_jayx> I have only done one review but the process is quite simple. Can one help out after the 5th of may ?
<keffie_jayx> sure
<nigelbabu> keffie_jayx, you can help out at any point. the 5th may is only a day to get lots of people engaged.
<nigelbabu> I hope to have everyone review at least one patch per day :)
<nigelbabu> keffie_jayx, you want to translate immediately or after May 5?
<keffie_jayx> great. I am getting some of the people in my city going with the little things I know about ubuntu development and patch reviewing has been suggested as a simple starting point
<keffie_jayx> nigelbabu: I could help now
<dholbach> keffie_jayx: nigelbabu and I were hoping to factor in some feedback into the page before may 5th, so it might make sense to have a look at the page again closer to the time
<nigelbabu> that's great.  I've been hoping to have patch review be the simple start point
<dholbach> but I epxect "just additions" like more examples and stuff
<nigelbabu> keffie_jayx, if you're starting now, just be subscribed to the page, so you can be alerted when we make changes
<dholbach> this is going to be awesome
<dholbach> I just know it
<keffie_jayx> ok
<nigelbabu> keffie_jayx, thank you for helping.  any help at any point, let me know.  will be glad to help :)
<keffie_jayx> let me subscribe to the wiki and also see if I can remember some of the process
<qense> dholbach: Will Mergimus be discussed during the UDS? I'm attending and I saw you have two blueprints on the patch review initiative. I've offered nigelbabu my help with writing Mergimus and I was wondering what session would be best for me to attend.
<nigelbabu> keffie_jayx, also, any feedback on the process is very much welcome :)
<dholbach> qense: Mergimus is no requirement for following the process outlined on the wiki
<keffie_jayx> nigelbabu: the process intends to be simple, However, Ihave a knack for running into brickwalls ... ain't that right dholbach?
<dholbach> qense: but we can sure discuss it
 * dholbach hugs keffie_jayx
<keffie_jayx> nigelbabu: will do
<nigelbabu> Awesome!  Thank you.
<qense> dholbach: OK. I'll see it then.
<qense> There is already some code, but it doesn't do much yet. :)
<dholbach> qense: right
<nigelbabu> vish, ahhh
<nigelbabu> vish, compiz is our default.  Did you change to metacity
<dholbach> if mergimus can make the task of getting the source, applying the patch correctly, etc etc it can be part of the task
<dholbach> the thing is that the process requires the web browser too (upstream bug trackers, adding tags to LP, etc.)
<dholbach> so I dunno yet
<dholbach> but sounds like a good idea to discuss
<qense> At the moment it can get an authenticated launchpad object, display an empty notebook with two tabs and a TreeView where you can add the names of valid packages!
<keffie_jayx> nigelbabu: I remember the only patch I ever did was not resolved. I tried the patch and it worked. since upstream wouldn't pick it up. i believe that was that
<qense> and it has translation support, which is pretty pointless at the moment. But you can translate it already! :P
<keffie_jayx> nigelbabu: I guess I was expecting some kind of completion.
<nigelbabu> keffie_jayx, generally, we forward patches to upstream and hear their comments
<nigelbabu> if upstream refuses, its upto debian maintainer/ubuntu maintainer (if any) to make a call
<keffie_jayx> nigelbabu: I did that, and upstream seems to have abandomed the app imho
<nigelbabu> keffie_jayx, ah.  In that case, you can look at changelog and see who upload and get in touch with that person
<keffie_jayx> the bugis also in debian and no call from them either
<nigelbabu> what package?
<keffie_jayx> tsclient
 * keffie_jayx fetches for the bug
<vish> nigelbabu: just what i was thinking when i was away :D , gonna test that
<nigelbabu> vish, I remembered when didrocks told me :)
<vish> !test
<ubot3> hrm?
<keffie_jayx> nigelbabu:  https://bugs.launchpad.net/ubuntu/+source/tsclient/+bug/63412
<ubot3> Malone bug 63412 in tsclient "Few resolution options" [Wishlist,New]
<keffie_jayx> nigelbabu:  it is also an app that at the time was in main, so I guess the desktop team had to decide on it.
<vish> nigelbabu: yay , works with metacity..
<nigelbabu> keffie_jayx, when patching something under desktop team.  the easy way is check with them :)
<vish> but noticed what didrocks mentioned
<nigelbabu> vish, that is for poppler bug
<vish> ah..
<keffie_jayx> nigelbabu:  the status of the bug is still new... after 3 years should I mark it as triaged at least?
<nigelbabu> vish, can you look into the ^ bug? (I'm hunting through fedora cvs)
<vish> keffie_jayx: if the bug has enough info , btw bug# ?
<keffie_jayx> vish:  https://bugs.launchpad.net/ubuntu/+source/tsclient/+bug/63412
<ubot3> Malone bug 63412 in tsclient "Few resolution options" [Wishlist,New]
<keffie_jayx> it has quite a few comments
<vish> keffie_jayx: yup that can be set to triaged..
<vish> sad that upstream hasnt commented on the patch though ..
<vish> keffie_jayx: any reason you changed the bug from confirmed -> new?
<keffie_jayx> honestly I can't remember doing that
<keffie_jayx> it's been a while, confirmed is the right status then?
<vish> keffie_jayx: triaged would be better
<keffie_jayx> vish: the app has a devel branch that does not see activity for more than 2 years. Fedora already ships the latest code from them. shouldn't a package upgrade be an option here?
<nigelbabu> vish, how on earth are we supposed to make sense of fedora CVS?
<vish> keffie_jayx: i didnt understand , what you said..
<vish> nigelbabu: hehe , dont know :D , i never looked at fedora bugs ;)  try google
<nigelbabu> vish, no no, I'm looking for the commit
<vish> nigelbabu: try the bug first , it would probably have a link
<keffie_jayx> vish: the patch is for a stable version of tclient, however there is a newer version, and debian has a bug indicating an update. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530953
<ubot3> Debian bug 530953 in tsclient "New version available: tsclient" [Wishlist,Open]
<keffie_jayx> vish:  and that would be desktop teams call I guess
<nigelbabu> keffie_jayx, can you ask lool about this?  he's part of the debian gnome team that takes care of this
<vish> keffie_jayx: yeah , not really a review team matter , pitti has already commented on the bug , it is more of a Main sponsors issue now
<keffie_jayx> vish: good then...
<keffie_jayx> dholbach: harvest tricked me...
 * keffie_jayx runs
<dholbach> keffie_jayx: I hope we get the new version online soon
<nigelbabu> keffie_jayx, pitti summarises what I feel about the patch too.
<nigelbabu> The patch is so big, we'd generally leave it to upstream to take care of it.  Asking debian folks is a good idea too.  Open bug in Debian BTS with patch and see what happens
<nigelbabu> james_w, you're james-w at ubuntu dot com?
<james_w> james.westby
<nigelbabu> ha, thank you :)
<nigelbabu> dholbach, when you're fee just let me know
<dholbach> nigelbabu: I am
<nigelbabu> dholbach, ok, so the mail should have info about monday and review of wiki.  anything else?
<dholbach> nigelbabu: sounds good to me
<nigelbabu> :)
<nigelbabu> sent :)
#ubuntu-reviews 2010-04-20
<dholbach> good morning
<vish> dholbach: nigelb: http://dl.dropbox.com/u/1325768/Review-team.png and  http://dl.dropbox.com/u/1325768/review-192.png
 * nigelb hugs vish, the rockstar :)
<vish> :)
<nigelb> its a beauty :)
<vish> thanks.. :)
<dholbach> is "forwarding patches" the only thing the team does?
<dholbach> I'm talking about the 192x192 version
<nigelb> dholbach, he meant "Fast Forward" i.e. do it quickly
<dholbach> aha, hm
<nigelb> you know the setting on the old VCP "Fast Forward"
<dholbach> alright
<dholbach> all set
<dholbach> thanks :)
<nigelb> where does the really big icon figure?
<dholbach> I dunno
<nigelb> haha :)
<vish> nigelb:  64px is used on lp ..  192px > no where ;p  , its normally used if people want to use as a banner
<nigelb> vish, I was wondering where the really big one figured on LP
<vish> nigelb: i have never seen it used anywhere on LP .. i would like to know as well :)
<nigelb> vish, great.  I'll use it on the wiki then :)
<nigelb> vish, did the icon thingie.. wonder how to put the big one
<vish> nigelb: for that you have , to add the image inline something like :
<nigelb> I know.  I'm wondering about placement actually
<vish> <<BR>>
<vish> {{http://blah/banner.png-20091222220929-jok8hkkxn07szdp4-1/banner.png}}
<vish> <<BR>>
<nigelb> not the technicality
<vish> ah righto..
<nigelb> just after header would look okay?
<vish> nigelb: usually next to the TOC , but there is no toc on the wiki ;)
<vish> nigelb: or next to the "what is review team" on the right
<nigelb> vish, do you know how to align it?
<vish> nigelb: float:right ?
<nigelb> vish, erm, not sure.  have to try
<vish> nigelb: that should work..
<nigelb> vish, yaay https://wiki.ubuntu.com/ReviewersTeam
<vish> nigelb: neat!
<nigelb> looks trendy with the new font that you used
<nigelb> vish, http://identi.ca/notice/29260810 :D :D
<nigelb> ouch, I spelled wrong, whatever..
<vish> nigelb: hehe ;p
<vish> dholbach: all the hugging started on this day or even earlier > http://www.youtube.com/watch?v=4jzGIaZcGcM  ? :D
 * vish blames dholbach of all Ubuntu Hugs ;p
<dholbach> even earlier :)
<vish> ;)
<nigelb> lol
<nigelb> vish, get ready to be crushed by dholbach and gag
<nigelb> gang
<nigelb> persia, I think I Pm'd you yesterday.  any comments?
<persia> I think my comments have to wait for me to read my email :)
<nigelb> ah
#ubuntu-reviews 2010-04-21
<dholbach> good morning
#ubuntu-reviews 2010-04-22
<dholbach> good morning
<dholbach> nigelb: could you imagine giving a session about patch review stuff for https://wiki.ubuntu.com/Packaging/Training?
<dholbach> nigelb: maybe some time in may or june?
<nigelb> dholbach, already part of UOW, want one more?
<dholbach> yeah, I could imagine that it'd be good to keep the flow of information going
<dholbach> did anybody follow up about Monday?
<dholbach> or feedback about the process?
<nigelb> dholbach, it might end up with you, me, and persia :D
<dholbach> or we advertise it a bit more
<nigelb> I'll poke friends over the weekend to put in a few hours
<dholbach> great
<dholbach> Âµblogged about it
<nigelb> oh yes
<nigelb> http://justanothertriager.wordpress.com/2010/04/20/patch-day-lite-and-other-updates/
<dholbach> yeah, linked to it
<nigelb> dholbach, you do know that Âµ is pronounced as "mew" right? ;)
<dholbach> http://identi.ca/notice/29542683 http://twitter.com/dholbach/status/12645222173
<persia> It happens to also be the SI prefix pronounced "micro"
<dholbach> micro :)
<nigelb> bah, I'm out of touch with physics
 * nigelb hangs head in shame
 * dholbach hugs nigelb
<nigelb> :)
 * vish pokes nigelbabu .. its friday!  time to get the patches in ;p
#ubuntu-reviews 2010-04-23
<nigelbabu> vish: friday for desktop team hits only in the afternoon :)
<dholbach> good morning
<keffie_jayx> hey guys
<keffie_jayx> I had a look at some of the bugs with patches and some of the stuff there is Really old.
<persia> Hey keffie_jayx
<persia> Yep.
<persia> But *really old* doesn't always mean *doesn't work*
<persia> We still need to check if it's a bug, if the patch fixes it, etc.
<persia> Many of them probably end up as patch-needswork, but ...
<keffie_jayx> ok
<keffie_jayx> I wanted tocheck first, I though I saw some people sayin, "hey this is too old go a ceck if it still happens in X release"
<persia> That's just laziness.
<persia> Lots of stuff doesn't get fixed for years.
<persia> That said, old patches may well not apply, but if they do, and they fix the bug, upstream wants to know.
<keffie_jayx> got it
<keffie_jayx> there is also package upgrade request... ignore those?
<keffie_jayx> ore remove the patch tag?
<keffie_jayx> example https://bugs.launchpad.net/ubuntu/+source/meld/+bug/417369
<ubot3> Malone bug 417369 in meld "update meld to 1.3.1 " [Unknown,Fix released]
 * persia looks
<persia> keffie_jayx: I'd mark that patch-accepted-debian and then let it sit for a couple weeks.
<keffie_jayx> in this one there is no upstream patch to send because it was precisely an upgrade from their pacckage
<keffie_jayx> coming from upstream
<persia> RIght, so no need for patch-submitted-upstream or patch-submitted-debian because it's already there.
<persia> patch-accepted-upstream is meaningless, because it's a new version.  patch-accepted-debian is useful because it gets the right tag for us to push through during maverick merges.
 * persia is expecting those of us who can upload to push through the patch-accepted-debian stuff in a hurry at the start of the maverick cycle, just to close them.
<keffie_jayx> welll do count on little ants like me, I am still scavaning the 2000~ bugs
<keffie_jayx> https://bugs.launchpad.net/ubuntu/+source/at/+bug/433545
<ubot3> Malone bug 433545 in at "at command ignores savings time when given UTC time" [Unknown,Confirmed]
<keffie_jayx> I am not sure debian acceped it
<keffie_jayx> the bug is filed and confirmed there
<keffie_jayx> the patch was submitted
<keffie_jayx> I already got patch-forwarded-debian
<keffie_jayx> but should I check to see if the patch is in the new version?
<keffie_jayx> the patch still applies btw
<bjernas_tresno> ?
<nigelbabu> grrr! Why is linux package patches getting into review queue again :/
<nigelbabu> hyperair: what are you doing on Monday?
<nigelbabu> will be able to spare a few hours?
<hyperair> nigelbabu: exams.
<nigelbabu> oh.  ah.
<hyperair> hours no, minutes yes, as long as it's under 15 ;-)
<nigelbabu> hyperair: basically just review a patch or 2 and flesh out ease of use of review guide
<nigelbabu> bdmurray: did I mess up the patch subscription script?  It seems to be subscribing 'linux' pacakge now
<bdmurray> nigelbabu: do you have an example?
<nigelbabu> bug 325581
<ubot3> Malone bug 325581 in xserver-xorg-input-evdev "kensington pocket mouse model #72237 USB 0d62:1000 not working under 8.10" [High,Triaged] https://launchpad.net/bugs/325581
<nigelbabu> ah, grr
<nigelbabu> its that multiple packages on same bug issue
<bdmurray> nigelbabu: yep
<bdmurray> I think that's the right thing to do
<nigelbabu> it is, I wishe there was a way to hide one of the tasks
<bdmurray> or associate the patch with a package? ;-)
<nigelbabu> yeah.
<nigelbabu> probably smething like the new sponsorship list looks like.
<nigelbabu> It should make things easier for review.
<nigelbabu> dholbach: what language the sponsorship list written in?
<hyperair> nigelbabu: i don't think i can make time for that, sorry.
<nigelbabu> hyperair: no problem :)
<dholbach> nigelbabu: python: https://launchpad.net/ubuntu-sponsoring
<nigelbabu> dholbach: thank you.  I'm thinking of something similar for review.  lemme see what I can come up with :)
<dholbach> ROCK :)
<nigelbabu> dholbach: I can get something done by June.  the code looks easy enough to hack for us :)
<dholbach> nice
<dholbach> so we'll improve slowly but steadily
<dholbach> I look forward to Monday
<nigelbabu> me too.  I'll try to take a day off work to be around te whole day :)
<nigelbabu> dholbach: doubt.
<nigelbabu> wht does your commit come in blue and mine in black?
<nigelbabu> https://code.launchpad.net/~nigelbabu/ubuntu-review-overview/trunk
<nigelbabu> https://code.launchpad.net/~dholbach/ubuntu-sponsoring/trunk
<dholbach> maybe to show that's where it was branched
<dholbach> but I need to rush off now
<dholbach> have a great day
<dholbach> see you!
#ubuntu-reviews 2010-04-24
<nigelbabu> our crazy review queue is up to 143 bugs
<nigelbabu> and I was worried about running out of bugs for patch day
<persia> We'll never run out: we might catch up, but we can trust other folks to always give us more.
<nhandler> nigelbabu: I am interested in seeing what happens after the maverick repos open up. We will get a lot of uploads as well as a lot of submitted patches
<nigelbabu> nhandler: yes, it might be *very* interesting
<persia> I think the lucid release is likely more a factor than maverick open, in terms of patch submission.
<nigelbabu> yes, but maverick being open gets us the change to integrate in a lot of pachtes
<nigelbabu> *patches
<nigelbabu> btw, I'm trying to get a review page similar to the sponsorship overview
<persia> How do you mean "trying"?
<persia> Do you just need hosting?
<persia> Or are you still fiddling with code?
<nigelbabu> starting to fiddle with code
<nigelbabu> my people.ubuntu stuff sould be okay for hosting
<persia> OK.  Hosting is fairly easy, and I know several ways to do that :)
<persia> people.ubuntu.com can't run code: only host static stuff.
<nigelbabu> or I can convince brian to put it up
<nigelbabu> I thought the python gave out an html page
<persia> It does, but you want to run the python every couple minutes.
<persia> Personally, I think the sponsorship report has less functionality than custom LP lists.
<nigelbabu> oh yeah.  well, let me get there first :)
<nigelbabu> well, it does keep out multiple copies of smae bug
<persia> The main reason I support it is that there are multiple groups of developers who need different sponsors lists, and I agree that those submitting sponsor requests shouldn't have to know who to subscribe.
<persia> I don't think we need that for reviewers.
<nigelbabu> Why I'm looking to an overview page is to avoid the complex queries and just point a page to show what needs to be reviewed.
<persia> How does it differ from the queries?
<nigelbabu> Its similar for newer folks
<persia> It's trivial to hide static queries behind nice pretty links.
<nigelbabu> /similar/simpler
<persia> How?
<nigelbabu> I wanted a way to keep track of patch-fowarded-upstream where the upstream bug is closed
<nigelbabu> and a coupla other use cases
<persia> Ah, so the report would actually categorize stuff, etc.
<nigelbabu> yes
<persia> Whereas with LP all we can do is produce lists, but not an overview.
<nigelbabu> hence the *starting* to fiddle with code
<persia> OK.  Please focus on making it a nice report/set of reports that tells us what is where, rather than on making it a landing page for reviewers to work from.
 * persia believes any non-realtime report is inherently broken as a worklist
<nigelbabu> In that case can you help me write down goals?
<nigelbabu> Its more of a summary to look at
 * persia should learn to be less expressive in the hopes of one day establishing a manageable activity list
<nigelbabu> hehe :)
<persia> Initial thoughts would be a summary overview of how many bugs are in which (descriptive) state based on analysis of tags (which is more than just raw tag count, which we can get easily from LP).
<persia> It would probably be interesting to produce a copy of this daily so we could later compare:analyse.  Maybe have the script generate a date-marked (e.g. filename) machine-readable set of data, and have another script that makes that pretty.
<persia> I believe most of the worklists *should* be able to be hidden behind URLs: I'm happy to toss that on the front page of qa.ubuntuwire.com instead of the current patch links, and they could also be put on the report.
<persia> If there exists a workqueue that can't be generated with an LP URL (like "bugs submitted upstream where the upstream task is closed"), then maybe generate worklists there (although I think this needs to update frequently).
<nigelbabu> So, something in the likes of a list of bugs with each status.
<persia> Note that in the case of patches-submitted-elsewhere-and-relevant-bugs-closed we need to differentiate between closures that imply patch acceptance and closures that imply patch rejection.  If we find that the algorithm manages to differentiate these successfully with no false positives, we can probably drop the workqueue lists, and instead have the script just mark for acceptance or rejection.
<persia> I don't think the lists of bugs with each status is useful *except* if we define a workqueue that can't be searched in LP.
<persia> Or rather, can't be defined with a URL.
<persia> (so it requires API to develop it).
<persia> That said, I think the right way to determine which workqueues to generate should be to try to figure out a set of bugs that has a known correct action (e.g. patch-submitted-upstream -> patch-accepted-upstream).
<nigelbabu> i.e. a point where we might have to work on it.
<persia> And then use the workqueues as tools to improve the algorithm with an eye towards automation.
<nigelbabu> +1
<persia> Note that this is *very* different than how the sponsors report works, although the sponsors report code may be a useful example to base some of the analysis upon.
<nigelbabu> its just base code so that I dont have to do the initial ground work
<nigelbabu> http://pad.ubuntu-uk.org/7a7QjBIyuq
<nigelbabu> I'm working on a rough cut of what needs to be done
<persia> Makes sense.
<persia> I'd probably try to focus on patch states, rather than which tags happen to be present.
<persia> So "How many bugs are currently waiting for upstream comment?" is an interesting metric.
<nigelbabu> ah, that way
<persia> And fot athat, I'd want to count patch-submitted-upstream AND NOT patch-accepted-upstream or patch-rejected-upstream.  The docs say that we're supposed to replace the tags, but I'm not confident everyone follows docs well.
<nigelbabu> So, we don't use the tags at all in the reports.
<persia> I don't think it's worthwhile to expose the actual tags.
<nigelbabu> I agree
<persia> That just leads to rough human estimates of interesting values by comparing the numbers.
<persia> If we're doing computational analysis, we can provide more interesting interpretation
<nigelbabu> Now, I remember why I hated hacking on LP API
<nigelbabu> Poor documentation.
<persia> nigelbabu: On (a)(ii): the analysis should be done for each bug, rather than doing arithmetic on the counts (you may already know this, but it wasn't clear to me from etherpad)
<persia> nigelbabu: I think it's also interesting to look at the total number of bugs that would be in the review queue if there wasn't a date restriction (so apply the same filters (excepting the date filter) as the script)
<nigelbabu> persia: I did know about (a)(ii)
<nigelbabu> and total number is already ready :)
<nigelbabu> I'm planning to take numbers using brian's script from the graphs
<persia> Do we have total numbers with the filters (sponsors, kernel, etc.)?
<nigelbabu> ah
<persia> My rough estimate is that we'd get down to ~1500 with the filter, but that's a complete guess.
<nigelbabu> for (a)(ii), you wanted patch-forwarded-upstream+patch-forwarded-debian+-patch-accepted-upstream+-patch-accepted-debian+-patch-rejected-upstream+-patch-rejected-debian
<nigelbabu> well, thats from modifying the link's query
<persia> Well, kinda.
<persia> I just suggested doing real analysis.
<nigelbabu> Only, I get no hits with that one :x
<persia> If you do that check for each bug iteratively (rather than doing arithmetic later), you should get the number of bugs waiting for upsteam feedback.
<persia> OTher interesting numbers would be a count of how many patches have been accepted usptream.
<persia> Or a count of how many patches have been applied upstream that still have open Ubuntu bugs.
<persia> (indicating how far we're behind on integration)
<persia> I'm sure there are others, but once you have a few, I suspect you'll get requests for more.
<nigelbabu> Thats the plan so far :)
<nigelbabu> for the places we have work to do, I'll just make a table or link to a query
<persia> Please don't.
<persia> Instead, for the candidates for automation, generate a table so we can review that the automation is safe to enable.
<persia> For the worklists, try to construct URLs for realtime LP queries.
 * persia reads ago.
<persia> s/ago/again/
<nigelbabu> Isn't that what I just said?
<persia> Right.  Please *DO* :)  Just differentiate in the way I describe :)
<nigelbabu> yup,sure :)
<nigelbabu> Only this can only happen in stages.
<nigelbabu> I'll first work on getting the numbers out
<persia> Sounds like a plan :)  Let me know if you need hosting (either realtime, or cronjob).
<nigelbabu> okay :)
<nigelbabu> Is it normal that I end up doing support stuff for the team than actual patch review?
<persia> In all the teams where I have accepted a leadership or administrative role, I've found that I have greatly reduced time to spend doing the actual work of the team.
<nigelbabu> Well, so that explains that.
<persia> When I'm not spending time thinking about how to improve how the team works, I'm spending time supporting other folks on the team with their goals.
<nigelbabu> So far similar to what I've been doing.
<persia> Yep.  You're the team leader for this team :)
<nigelbabu> I *hate* LP API!
<nigelbabu> (and it seems to hate me equally)
<nigelbabu> looks like I neeed help figuring out how LP API deals with tag combinations
<persia> #launchpad :)
<nigelbabu> weekend
<nigelbabu> Note to self: Trial and error /works/
<persia> Well, and bad time of day for the couple folks that tend to be around on weekends.
<nigelbabu> I figured it out.  API documentation is just bad.
<nigelbabu> instead of whitespace I needed a =
<nigelbabu> + rather
<nigelbabu> patch-forwarded-upstream shows 3 bugs with patches and patch-forwarded-upstream+patch-forwarded-debian shows 0
<nigelbabu> wonder why
<persia> paste code?
<nigelbabu> http://paste.ubuntu.com/421691/
<nigelbabu> I've worked on the code than brian uses for generating graphs
<persia> Actually, based on our workflow, I would expect that the number of bugs with that combination would be 0.
<persia> We haven't gone back to the patch-forwarded-upstream bugs and decided upstream was far too slow, and done forwarding to Debian yet.
<nigelbabu> ah, I have to try something with two tags to see if that works
<nigelbabu> Even with Any combination/
<nigelbabu> ok, thiss is totally cuckoo!  Whats works on LP site doesn't work via API
<persia> That doesn't suprise me.
<persia> An increasing amount of the web interface is being refactored to use the API, but it's not complete in any way.
<nigelbabu> I'm not sure if tag combinations work via API.
<persia> And there's extra oddities: like the behaviour of things being different if you use/don't use the Javascript interface.
<nigelbabu> I tried using whitespace to separate two tags and also +, still returns 0
<persia> You could grab all the bugs that have some specific tag, and then select a subset (using Python's set interface) where they also have (or don't have) some other tag.
<nigelbabu> grabbing bug by bug is very inefficient.  It takes a loong time.
<persia> That said, I can barely patch typo bugs in Python, so I can't really help you do that :)
<persia> No, grab a set of bugs that have tag A.
<persia> Stick them in a set.
<persia> Then create a subset from that set, based on properties of the bugs (not requerying LP).
<nigelbabu> Ah, that *might* work
<nigelbabu> I need food first.
<persia> Depends on whether you have local access to the bug properties.  I don't know the data structures.
<persia> But that algorithm should get you the right set.
<nigelbabu> subsetting might involve querying LP again
<vish> nigelbabu: did the cheese apport hook land for karmic as well?
<nigelbabu> vish: no.  need sru for that.
<vish> nigelbabu: hmm , a lot of the bugs are from karmic users.. would it get an sru?
<nigelbabu> vish: can ask someone from ~ubuntu-sru?
<vish> righto..
