| nigelbabu | our crazy review queue is up to 143 bugs | 00:55 |
|---|---|---|
| nigelbabu | and I was worried about running out of bugs for patch day | 00:55 |
| persia | We'll never run out: we might catch up, but we can trust other folks to always give us more. | 00:57 |
| 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 | 02:14 |
| nigelbabu | nhandler: yes, it might be *very* interesting | 13:11 |
| persia | I think the lucid release is likely more a factor than maverick open, in terms of patch submission. | 13:11 |
| nigelbabu | yes, but maverick being open gets us the change to integrate in a lot of pachtes | 13:13 |
| nigelbabu | *patches | 13:13 |
| nigelbabu | btw, I'm trying to get a review page similar to the sponsorship overview | 13:14 |
| persia | How do you mean "trying"? | 13:14 |
| persia | Do you just need hosting? | 13:14 |
| persia | Or are you still fiddling with code? | 13:15 |
| nigelbabu | starting to fiddle with code | 13:15 |
| nigelbabu | my people.ubuntu stuff sould be okay for hosting | 13:15 |
| persia | OK. Hosting is fairly easy, and I know several ways to do that :) | 13:16 |
| persia | people.ubuntu.com can't run code: only host static stuff. | 13:16 |
| nigelbabu | or I can convince brian to put it up | 13:16 |
| nigelbabu | I thought the python gave out an html page | 13:17 |
| persia | It does, but you want to run the python every couple minutes. | 13:17 |
| persia | Personally, I think the sponsorship report has less functionality than custom LP lists. | 13:18 |
| nigelbabu | oh yeah. well, let me get there first :) | 13:18 |
| nigelbabu | well, it does keep out multiple copies of smae bug | 13:18 |
| 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. | 13:18 |
| persia | I don't think we need that for reviewers. | 13:18 |
| 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. | 13:20 |
| persia | How does it differ from the queries? | 13:20 |
| nigelbabu | Its similar for newer folks | 13:20 |
| persia | It's trivial to hide static queries behind nice pretty links. | 13:20 |
| nigelbabu | /similar/simpler | 13:20 |
| persia | How? | 13:20 |
| nigelbabu | I wanted a way to keep track of patch-fowarded-upstream where the upstream bug is closed | 13:21 |
| nigelbabu | and a coupla other use cases | 13:21 |
| persia | Ah, so the report would actually categorize stuff, etc. | 13:21 |
| nigelbabu | yes | 13:22 |
| persia | Whereas with LP all we can do is produce lists, but not an overview. | 13:22 |
| nigelbabu | hence the *starting* to fiddle with code | 13:22 |
| 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. | 13:22 |
| * persia believes any non-realtime report is inherently broken as a worklist | 13:23 | |
| nigelbabu | In that case can you help me write down goals? | 13:23 |
| nigelbabu | Its more of a summary to look at | 13:23 |
| * persia should learn to be less expressive in the hopes of one day establishing a manageable activity list | 13:24 | |
| nigelbabu | hehe :) | 13:24 |
| 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). | 13:28 |
| 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. | 13:29 |
| 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. | 13:30 |
| 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). | 13:31 |
| nigelbabu | So, something in the likes of a list of bugs with each status. | 13:32 |
| 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. | 13:33 |
| 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. | 13:33 |
| persia | Or rather, can't be defined with a URL. | 13:33 |
| persia | (so it requires API to develop it). | 13:34 |
| 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). | 13:34 |
| nigelbabu | i.e. a point where we might have to work on it. | 13:34 |
| persia | And then use the workqueues as tools to improve the algorithm with an eye towards automation. | 13:35 |
| nigelbabu | +1 | 13:35 |
| 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. | 13:35 |
| nigelbabu | its just base code so that I dont have to do the initial ground work | 13:36 |
| nigelbabu | http://pad.ubuntu-uk.org/7a7QjBIyuq | 13:38 |
| nigelbabu | I'm working on a rough cut of what needs to be done | 13:38 |
| persia | Makes sense. | 13:43 |
| persia | I'd probably try to focus on patch states, rather than which tags happen to be present. | 13:43 |
| persia | So "How many bugs are currently waiting for upstream comment?" is an interesting metric. | 13:44 |
| nigelbabu | ah, that way | 13:44 |
| 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. | 13:44 |
| nigelbabu | So, we don't use the tags at all in the reports. | 13:45 |
| persia | I don't think it's worthwhile to expose the actual tags. | 13:51 |
| nigelbabu | I agree | 13:51 |
| persia | That just leads to rough human estimates of interesting values by comparing the numbers. | 13:51 |
| persia | If we're doing computational analysis, we can provide more interesting interpretation | 13:51 |
| nigelbabu | Now, I remember why I hated hacking on LP API | 13:56 |
| nigelbabu | Poor documentation. | 13:57 |
| 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) | 14:16 |
| 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) | 14:17 |
| nigelbabu | persia: I did know about (a)(ii) | 14:18 |
| nigelbabu | and total number is already ready :) | 14:18 |
| nigelbabu | I'm planning to take numbers using brian's script from the graphs | 14:18 |
| persia | Do we have total numbers with the filters (sponsors, kernel, etc.)? | 14:19 |
| nigelbabu | ah | 14:20 |
| persia | My rough estimate is that we'd get down to ~1500 with the filter, but that's a complete guess. | 14:21 |
| nigelbabu | for (a)(ii), you wanted patch-forwarded-upstream+patch-forwarded-debian+-patch-accepted-upstream+-patch-accepted-debian+-patch-rejected-upstream+-patch-rejected-debian | 14:22 |
| nigelbabu | well, thats from modifying the link's query | 14:22 |
| persia | Well, kinda. | 14:24 |
| persia | I just suggested doing real analysis. | 14:25 |
| nigelbabu | Only, I get no hits with that one :x | 14:25 |
| 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. | 14:25 |
| persia | OTher interesting numbers would be a count of how many patches have been accepted usptream. | 14:27 |
| persia | Or a count of how many patches have been applied upstream that still have open Ubuntu bugs. | 14:28 |
| persia | (indicating how far we're behind on integration) | 14:28 |
| persia | I'm sure there are others, but once you have a few, I suspect you'll get requests for more. | 14:28 |
| nigelbabu | Thats the plan so far :) | 14:30 |
| nigelbabu | for the places we have work to do, I'll just make a table or link to a query | 14:30 |
| persia | Please don't. | 14:33 |
| persia | Instead, for the candidates for automation, generate a table so we can review that the automation is safe to enable. | 14:34 |
| persia | For the worklists, try to construct URLs for realtime LP queries. | 14:34 |
| * persia reads ago. | 14:34 | |
| persia | s/ago/again/ | 14:34 |
| nigelbabu | Isn't that what I just said? | 14:34 |
| persia | Right. Please *DO* :) Just differentiate in the way I describe :) | 14:35 |
| nigelbabu | yup,sure :) | 14:35 |
| nigelbabu | Only this can only happen in stages. | 14:35 |
| nigelbabu | I'll first work on getting the numbers out | 14:35 |
| persia | Sounds like a plan :) Let me know if you need hosting (either realtime, or cronjob). | 14:39 |
| nigelbabu | okay :) | 14:39 |
| nigelbabu | Is it normal that I end up doing support stuff for the team than actual patch review? | 14:40 |
| 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. | 14:42 |
| nigelbabu | Well, so that explains that. | 14:42 |
| 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. | 14:42 |
| nigelbabu | So far similar to what I've been doing. | 14:44 |
| persia | Yep. You're the team leader for this team :) | 14:49 |
| nigelbabu | I *hate* LP API! | 14:51 |
| nigelbabu | (and it seems to hate me equally) | 14:51 |
| nigelbabu | looks like I neeed help figuring out how LP API deals with tag combinations | 14:53 |
| persia | #launchpad :) | 14:55 |
| nigelbabu | weekend | 14:56 |
| nigelbabu | Note to self: Trial and error /works/ | 14:57 |
| persia | Well, and bad time of day for the couple folks that tend to be around on weekends. | 14:57 |
| nigelbabu | I figured it out. API documentation is just bad. | 14:57 |
| nigelbabu | instead of whitespace I needed a = | 14:57 |
| nigelbabu | + rather | 14:58 |
| nigelbabu | patch-forwarded-upstream shows 3 bugs with patches and patch-forwarded-upstream+patch-forwarded-debian shows 0 | 14:59 |
| nigelbabu | wonder why | 14:59 |
| persia | paste code? | 14:59 |
| nigelbabu | http://paste.ubuntu.com/421691/ | 15:00 |
| nigelbabu | I've worked on the code than brian uses for generating graphs | 15:00 |
| persia | Actually, based on our workflow, I would expect that the number of bugs with that combination would be 0. | 15:03 |
| 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. | 15:03 |
| nigelbabu | ah, I have to try something with two tags to see if that works | 15:04 |
| nigelbabu | Even with Any combination/ | 15:06 |
| nigelbabu | ok, thiss is totally cuckoo! Whats works on LP site doesn't work via API | 15:12 |
| persia | That doesn't suprise me. | 15:13 |
| persia | An increasing amount of the web interface is being refactored to use the API, but it's not complete in any way. | 15:13 |
| nigelbabu | I'm not sure if tag combinations work via API. | 15:14 |
| persia | And there's extra oddities: like the behaviour of things being different if you use/don't use the Javascript interface. | 15:14 |
| nigelbabu | I tried using whitespace to separate two tags and also +, still returns 0 | 15:14 |
| 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. | 15:15 |
| nigelbabu | grabbing bug by bug is very inefficient. It takes a loong time. | 15:15 |
| persia | That said, I can barely patch typo bugs in Python, so I can't really help you do that :) | 15:16 |
| persia | No, grab a set of bugs that have tag A. | 15:16 |
| persia | Stick them in a set. | 15:16 |
| persia | Then create a subset from that set, based on properties of the bugs (not requerying LP). | 15:16 |
| nigelbabu | Ah, that *might* work | 15:17 |
| nigelbabu | I need food first. | 15:17 |
| persia | Depends on whether you have local access to the bug properties. I don't know the data structures. | 15:17 |
| persia | But that algorithm should get you the right set. | 15:17 |
| nigelbabu | subsetting might involve querying LP again | 15:18 |
| vish | nigelbabu: did the cheese apport hook land for karmic as well? | 15:29 |
| nigelbabu | vish: no. need sru for that. | 15:33 |
| vish | nigelbabu: hmm , a lot of the bugs are from karmic users.. would it get an sru? | 15:34 |
| nigelbabu | vish: can ask someone from ~ubuntu-sru? | 15:34 |
| vish | righto.. | 15:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!