21:04:18 #startmeeting bugzappers meeting 21:04:18 Meeting started Tue Dec 7 21:04:18 2010 UTC. The chair is mcepl. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:04:18 Useful Commands: #action #agreed #halp #info #idea #link #topic. 21:04:46 #chairs to add any others as chairs 21:04:58 boingy boingy 21:05:06 * adamw watching the progress meter on ddrescue with crossed fingers 21:05:29 #chairs mcepl adamw fenrus02 21:05:35 * fenrus02 takes a seat 21:05:48 * fcami stands in the back 21:05:56 op try #chair 21:05:57 http://piratepad.net/xVd9K5RamP is a tentative agenda, please add any items you think are worthy 21:05:58 * bsjones waves 21:06:17 * andrewjroth waves back! 21:06:21 hello and welcome bsjones :) 21:06:34 * adamw decides not to allow javascript access to a site called 'piratepad' 21:06:48 does anybody know whether there is already Fedoraproject Etherpad? 21:06:50 adamw, hehe! it's neat though. you can watch folks type 21:06:52 what's wrong with fpaste, really? :P 21:07:05 adamw, interactively add/update ... doesnt happen on fpaste 21:07:05 * fcami notes fenrus02 watches _others_ type 21:07:08 adamw: web-based gobby 21:07:15 fenrus02: all the more reason not to. i've typed my root password into the wrong window more than once :P 21:07:16 adamw: that five people cannot edit in the same time ... we could use gobby, but this is faster 21:07:29 adamw: there is no password 21:07:34 fcami, my typing skill is not measured in words-per-minute like most ... more like typos-per-second 21:07:36 adamw: so you treat IRC as read-only then? :) 21:07:52 fcami: you have to hit enter on irc 21:07:54 adamw, ok, google-wave is dead though 21:08:05 sorry to derail, anyway 21:08:07 fenrus02: Dead? how so? 21:08:11 fenrus02: it isn't, but let's try to behave for a second 21:08:21 (today it was taken over by Apache Foundation) 21:09:53 #topic Update https://fedoraproject.org/wiki/BugZappers/Components_and_Triagers ... do we have it up to date? 21:10:10 * fcami would like a chair 21:10:14 I was showing it to andrewjroth but I am really not sure how accurate it is 21:10:23 it's not, as far as I am concerned 21:10:33 fcami, what would you have it updated with ? 21:10:34 I'll remove myself, I can't make time. 21:10:55 i'm still vaguely doing X triage but only infrequently 21:11:00 i'm not really doing anything else atm 21:11:10 I can go on triaging stuff but cannot commit to triage regularly for a component now 21:11:14 fcami: that's OK, when I see two comments from you in a month, you are on ;) 21:11:29 mcepl :) 21:12:00 speaking of, did the metrics script die again? 21:12:30 what script? 21:12:57 did it ever work? 21:13:06 oh, guess that answers that. 21:14:47 we had two-threeish attempts at it 21:15:00 the last one was someone who joined earlier this year, i forget who; he got a few basic things working but not much more 21:15:08 * fenrus02 nods 21:15:31 https://fedoraproject.org/wiki/BugZappers/Metrics (and the talk page) is the stuff from that last effort 21:15:40 the actual commands are on the talk page 21:16:39 interesting, but is there any hope we would fix it? does anybody volunteer? 21:17:00 if not, let's go back to https://fedoraproject.org/wiki/BugZappers/Components_and_Triagers ... that should be more doable. 21:17:03 i think he came up against inadequacies in the tooling 21:17:10 like we needed something added to bugzilla or something 21:17:10 What to do with it? It would be nice to have something from incoming newbies. 21:17:32 * mcepl is backing up ... he doesn't want to interrupt 21:17:44 first of all, alphabetical order is not really the way to go, but we would need to script something better, so... 21:17:45 * andrewjroth apparently missing things... 21:17:47 are there any heat-maps for components? like what receives the most bug reports? 21:18:00 I mean, some components have 100+ NEW bugs, others have none 21:18:16 and it's not readily apparent from the list. but yeah, we would need a script to auto-update the wiki. 21:18:30 fenrus02: I guess that would be part of results from these scripts ;) 21:18:41 yeah, indeed. 21:18:57 mcepl, well, that's what i really cared about :) 21:19:09 I agree it would be nice to have 21:19:12 mcepl, if folks knew what was reported most, that could give some guidance to what is needed 21:19:27 * andrewjroth agrees with fenrus02 21:19:31 OTOH, we know the biggest hostspots ... they are same 21:19:53 (kernel, xorg*, firefox/thunderbird, some other desktop comoponents) 21:20:21 mcepl, do each of those hotspots have a "how to debug ___" page ? (i know some do, but if they are heavy use, they should have a dedicated page) 21:20:32 xorg hqs 21:20:35 *has 21:20:37 Xorg has 21:20:48 Firefox doesn't ... you need to talk with me 21:20:51 kernel, I have no idea 21:21:32 kernel is another thing that's been in the pipeline forever 21:21:37 can't remember who was working on that last either 21:21:48 do we really, really care? 21:21:53 I mean does #fedora-kernel care? 21:21:56 i care a bit! 21:22:05 yeah, me too, that's not the idea 21:22:08 they'd be happy to have help but aren't really likely to help us help them a whole lot 21:22:35 the main thing is, they take kernel.org, hack on it, include their own development branches, etc, etc 21:22:47 * nirik was. ;) 21:22:49 do they look at bugs for real except when we're composing beta or something? 21:22:58 kernel bug reports should likely have a smolt url though for instance 21:23:05 perhaps over the holidays I can get back to it, but it just dropped low on my list. 21:23:31 https://fedoraproject.org/wiki/KernelTriage 21:23:38 * mcepl notes he just learned about https://fedoraproject.org/wiki/User:Fenris02/Firefox ... will talk with fenrus02 about it later 21:24:05 if someone wants to take over spearheading kernel bugzapping, please feel free and I will support them as best I can. 21:25:08 well, they should have a mention https://fedoraproject.org/wiki/Bugs_and_feature_requests#Information_required_for_bugs_in_specific_components -- kernel does, xorg a few others. 21:25:12 smolt is pain ... I don't know if it is actually useful for kernel folks, it is mostly useless for Xorg. 21:25:24 triage should be able to look through that page and provide useful suggestions to the reporter 21:25:49 we definitively have https://fedoraproject.org/wiki/Xorg/Input_Triage_Algorithm 21:26:02 * mcepl is getting back and concentrating 21:26:25 and https://fedoraproject.org/wiki/Xorg/Debugging 21:27:13 I could sort the Debugging page a bit 21:27:20 we're mostly using KMS now 21:27:27 it should be more visible 21:27:31 yes 21:27:36 it needs to be updated 21:27:48 I'll do that 21:27:50 fcami: radeon's still ums-capable i think 21:27:58 on R400 and below 21:28:01 maybe R500 and below 21:28:12 not on anything people consider current 21:28:20 (IIRC) 21:28:29 #action mcepl talk with fenrus02 about Firefox triage page 21:28:42 #action mcepl talk with fcami about update of Xorg triage page 21:29:01 be good to link these component wikis to the Components_and_triagers page 21:29:14 adamw: and basically the Xorg devs do not want to maintain UMS anymore, we're nearly on par feature-wise now even on older hw so... 21:29:41 bsjones: or somewhere, yes 21:30:40 moreover nomodeset is not supported much ... if it is broken and KMS works, then we don't care 21:30:46 but back to our meeting 21:30:54 yes. 21:31:34 so, how we will update https://fedoraproject.org/wiki/BugZappers/Components_and_Triagers 21:31:51 should we go around developers and ask them about them about the current status? 21:32:01 I would like us to remove all the packages, even critpath, that have no or nearly no bugs 21:32:12 that would make the page clearer. example: openssh-server 21:32:32 that goes back to the heat-map idea (above) 21:32:36 indeed 21:32:44 fcami, any idea how to pull those stats out? 21:32:47 yes, and I am quite sure that its maintainer (sits next to me) doesn't want and doesn't need bug triager 21:32:48 s 21:32:59 script bz through the webservice. I think I can do it but -enotime for now. 21:33:28 i think we can do it with python-bugzilla actually 21:33:32 fcami, bugzilla cli panics if there are "too many bugs", and reports nothing at all. 101 appears to be "too many" fwiw. 21:33:49 we'd have to see if pybz does too 21:34:23 rather than lose them it'd be good to stick them in a subsidiary table at the bottom or something, but yeah, let's get them out of the way 21:34:41 +1 yes 21:35:07 mcepl, how do you feel about that in general? 21:35:31 fenrus02: I think before we have scripts, plan B would be to go around maintainers, or check number of current bugs manually 21:35:47 (in opposite order of steps) 21:36:03 mcepl, *nod* rather cumbersome if you want to look at more than say 5 or 10 packages. 21:37:11 it should be easier to hack it up via a web query or python-bugzilla query than do it manually. 21:37:27 it usually takes me about half an hour to bodge something up in python-bugzilla, it'd take a lot longer to go through each one of those manually, i think 21:37:36 if you add unpacked http://is.gd/imkDm to your firefox as keyword search (there is %s in the end) and name it something then you can searhc by componetns by one command 21:37:49 adamw: ^^^^ 21:38:08 http://fpaste.org/J438/ 21:38:26 so I just write 21:38:28 rhbz firefox 21:38:33 and I have all open bugs for firefox 21:39:25 and you don't have to go through them for assesing its importance ... just numbe rof bugs is enough 21:39:48 * fenrus02 nods 21:40:21 * nirik just has a shortcut for 'bugz %s' that does 'http://bugz.fedoraproject.org/%s' 21:40:28 okay, anyway 21:40:33 enough bikeshedding 21:40:40 someone say they'll do it and let's move on 21:40:49 OK, so he is willing to do the work ... any eager newbies around? 21:40:52 * adamw is not going to take on any major tasks at this meeting cos he's already overloaded with qa stuff 21:41:10 * mcepl too ... and he wants other to do something 21:41:23 * andrewjroth can do it... but would need guidance 21:41:27 I'm editing the kernel page 21:41:31 I'll do the Xorg pages afterwards 21:41:33 andrewjroth: I'll help you 21:42:19 alright... I don't know python that well, but I could learn 21:42:30 #action andrewjroth helped by mcepl will make an assesment for importance of all bugs 21:42:44 andrewjroth: I don't plan to use python, we'll talk 21:42:49 we just want a script to take the number of bugs and put it in the wiki table 21:42:51 ? 21:42:52 alright 21:43:01 We can talk off irc 21:43:06 well, make a table of it anyhow 21:43:15 fenrus02: yes 21:43:21 i suspect the ordering of the wiki will be a manual effort 21:44:08 * mcepl doesn't like proprietary solutions, but maybe this is the time for Google Docs? or OOo Calc file somewhere. 21:45:04 OK, anything more to this item? 21:45:25 * andrewjroth thinks the current list is daunting for newbies 21:45:37 three 21:45:40 two 21:45:45 one 21:45:50 #item Formally affirm the date and time of meeting (just it is recorded) 21:46:02 #topic Formally affirm the date and time of meeting (just it is recorded) 21:46:14 * andrewjroth updated the meeting time on the Wiki to this current time 21:46:17 andrewjroth: that's why we want to prioritize instead of showing a big list. 21:46:30 fcami: right! 21:46:50 andrewjroth: thanks 21:47:09 No problem! I updated it when I showed up at 10am and no one was here. :-P 21:47:10 anybody has anything against 21:00 UTC on Tuesday? Or do we want to meet biweekly? 21:47:39 that time is perfect for me 21:47:46 this time of day works well for me 21:48:09 I don't like it much, but it is doable ... better than no meeting at all 21:48:20 now is good 21:48:33 true... I would have prefered 10am, but I can understand not everyone is on Eastern time 21:48:41 I will settle for this time 21:48:59 adamw: ??? 21:49:11 mcepl, $work impacts my ability to make "early" meetings on most days. *shrugs* i'm sure everyone has a unique time that works best 21:49:29 this time's fine for me 21:49:36 fenrus02: it's 22:00 here :( 21:49:45 I'm supposed not to have IRC at $work so 21:49:55 OK, so no complaints? Speak now or hold your peace forever! 21:49:57 mcepl, *nod* understand 21:49:57 mcepl: here too *grin* 21:49:58 Since this meeting is currently at this time... there is no reason anyone here would object. 21:50:21 weekly or biweekly? 21:50:38 mcepl, tbh, we've been so long without a meeting at all - is there a need to have weekly? 21:51:11 * adamw is of the 'meet when we need to' school 21:51:37 adamw, well, meetings tend to shake the dust off projects that have been forgotten 21:51:45 If we start off at bi-weekly (first and third Tuesday?) we can increase frequency if needed. 21:51:49 is their usually much to cover? (my first meeting) 21:51:51 adamw: that's lovely ... but we need something to keep us in order (kind of Alcoholics Anonymous style) 21:52:00 moreover it is not good for newbies 21:52:03 (also my first meeting) so I don't know 21:52:20 heh, true 21:52:32 andrewjroth, bsjones - the -bz channel is always around if you have questions. no need to wait for a meeting 21:52:38 not much .... just what we are doing, how much we are doing on projects we took on, and of course there is more activity around release 21:52:48 fenrus02: +1000 21:52:55 fenrus02: I know... haven't waited... but wanted to see a meeting. 21:53:04 I am there every workday (CET time, but long into evening usually) 21:53:44 so votes? Weekly vs. Biweekly? 21:53:45 mcepl, every two weeks or 1st/3rd of each month as a start? keep tabs on any action items from last meeting? 21:54:19 * fenrus02 notes again that it would be positively awesome to have an ical for -meeting events 21:54:41 fenrus02: make one ;) 21:54:46 * andrewjroth would find it ammusing if IRC meetings followed to Robert's Rules of Order. 21:55:05 I was considering makeing a Google Calendar that is public for Meeting times 21:55:05 and yes, whatever will be the conclusion, we probably won't meet until next year. Agreed? 21:55:12 mcepl, wouldnt do much good if not all reservations took place on the cal that was exprterd 21:55:21 'exported' (erg!) 21:55:32 andrewjroth: we refrain from using proprietary solutions :) 21:55:43 So I hear... but it is a good solution. 21:55:53 for some definition of good. but anyway. 21:55:59 ical is not properietary, but whatever 21:55:59 mcepl: I'm ok for once a month. 21:56:00 whatever ... let's vote ... who is for biweekly meeting? 21:56:09 +1 21:56:21 err, bimonthly? or biweekly? 21:56:22 monthly sounds reasonable 21:56:35 fcami: montly is too much far from each other ... even if it would be fifteen minutes, I would prefer more often 21:56:49 every two weeks then. 21:56:52 biweekly then 21:56:54 that works 21:57:11 any opposition? 21:57:38 biweekly then from me as well 21:57:40 fcami, bi-weekly = every two weeks, bi-monthly = every two months ... 60 days between meetings is a bit high for any action items :P 21:58:06 yeah, I had it backwards. :) 21:58:09 #agreed meeting here every two weeks (next time 11th January 2011), 21:00 UTC 21:58:47 #topic Matěj's announcement of about the status of Jetpacks 21:59:34 just that current Firefox addon (https://fedorahosted.org/released/bugzilla-triage-scripts/bugzilla-triage-latest.xpi) is supported on Firefox 3.6.* and it is now in the maintenance mode (bugfixes only). 21:59:56 Firefox 4.* will require almost complete rewrite and it won't be compatible with FF 3.6.* 22:00:11 s/almost complete rewrite/substantial changes/ 22:00:12 new zappers, if you've not tried the triage xpi yet - check it out. very handy 22:00:15 working on it 22:00:53 mcepl, requires it because of jetpack updates, or refactoring in new ideas? 22:01:01 if you have any complaints, feature requests, catch me on #fedora-bugzappers or file a ticket on https://fedorahosted.org/bugzilla-triage-scripts/newtplticket 22:01:28 fenrus02: API was completely changed because of every-tab-is-an-independent-process in FF4 22:01:47 much more complicated for me 22:02:39 currently already some things don't work with current addon in FF4 (all privileged operations like XMLHttpRequest are disallowed) 22:02:43 mcepl, *nod* and thanks for doing it, very useful 22:03:17 any questions? 22:03:40 #topic fcami would like us to look at the tentative bodhi-updates-bz message he posted to test-list and bodhi last Saturday - http://lists.fedoraproject.org/pipermail/test/2010-December/095866.html 22:03:44 #chairs fcami 22:03:56 fcami: you have a mike 22:04:01 err 22:04:09 *mic* 22:04:10 what is it about? 22:04:25 so basically, when bodhi updates a bug because an update is pushed to testing 22:04:33 or from testing to stable 22:04:34 andrewjroth: sorry, bad spelling ... 22:04:43 it updates the bug with a very terse message 22:04:57 mcepl: It's cool... /me is a former audio tech. 22:05:00 yes, too terse 22:05:11 andrewjroth: me has Enlighs as second language ;) 22:05:15 *English 22:05:18 I wanted to change that message and posted the patch to do so - nirik pointed me at https://fedorahosted.org/fedora-infrastructure/ticket/701 22:05:30 I would like the bugzappers to have a look at what we want to see when a bug is updated 22:05:45 because of course, if a bug is not fixed by an update, we're going to have other open bugs 22:06:09 so if you guys could help me formulate something that works for us, I'll be grateful 22:06:26 * fcami gives the mic back to mcepl 22:06:59 fcami, when a push is made to stable, it would save time adding the comments to the bug reports. At least it can give the reporter a chance to update and retest 22:07:24 "adding the comments" means? 22:07:30 just from the first look "number of hours" is not enough for mirrors to propagate a package to Europe (not mentioning Asia and New Zealand) ... couple of days is more in line with reality, isn't it? 22:07:46 however, big +1 for the rewrite of the message 22:07:52 about a day I think, but yeah 22:08:05 ty mcepl 22:08:34 fcami, if the bug reports have comments indicating "package foo was updated from what you reported" then the reporter can update and retest 22:08:47 ah. 22:09:04 only problem is that when folks dont update, and then report bugs on version that have already been repaired ... 22:09:13 patch looks good to me 22:09:16 and instead of "Your feedback on this update would be much appreciated, and can be submitted via the above URL." I would just directly ask them to file change karma of the update 22:09:37 Please go to the above URL and .... 22:09:41 something of that kind 22:09:44 indeed 22:10:18 * bsjones has to jump on his bike and go to work 22:10:32 * fcami waves to bsjones :) 22:10:32 will pick it up there if you are still around. thanks and seeya! 22:11:06 bsjones, cheers 22:11:09 fcami: BTW, that's probably another ticket but https://admin.fedoraproject.org/updates/spectrum-1.4.4-1.fc14 would need some big button [DOWNLOAD PACKAGES HERE] 22:11:23 "package $foo was updated and should fix your issue. Please update it with the updates-testing repository and then file karma (feedback) on this update at $url as soon as you are able to." 22:11:29 if it is supposed to be the main point of contact 22:11:40 fcami: yes, much better 22:12:00 What if the update is not designed to fix the issue at hand? Or are we talking about a manual comment? 22:12:22 andrewjroth: supposedly the maintainer lists the bz #s when he/she pushes the update through bodhi 22:12:23 mcepl, you mean change "Builds:" to "Download:" ? 22:12:30 andrewjroth: when the package is filed to bodhi (update database) maintainer can say that this update fixes bug no. so-and-so 22:12:41 fenrus02: no I mean that bodhi should grow another feature 22:12:59 andrewjroth: then and only then this whole happens 22:13:01 mcepl: you want the "download rpm directly from koji" link in there? 22:13:06 yes 22:13:13 because otherwise reporter won't find it 22:13:13 I think it is discouraged 22:13:35 OK, then don't say ... "and manually download packages from" 22:13:50 hmmm 22:13:54 su -c 'yum update --enablerepo=updates-testing foo' 22:13:59 that works 22:14:01 * nirik notes the packages from koji are not signed. 22:14:06 yes 22:14:11 nirik: I agree 22:14:25 I don'ŧ want to promote downloading packages from koji 22:14:36 just that the text of messages did, IMHO 22:15:11 Package $foo was pushed to the updates-testing repository and should fix your issue. Please update it with su -c 'yum update --enablerepo=updates-testing foo', then reboot, and then file karma (feedback) on this update at $url as soon as you are able to. 22:15:33 mirror propagation delay is in the 1-2 days though. this may cause some questions 22:15:49 we need a faster c 22:16:04 fcami: do we really send THREE messages for each update? 22:16:15 I think 22:16:24 OMG :( 22:16:31 yeah 22:16:31 one send that has all three statements? 22:16:42 no, it's not like that 22:17:03 I think we need to send just one message "here is the packge and here is the webpage for karma" 22:17:12 so send it only when it is ready 22:17:23 yeah, but we don't know when the mirror is ready 22:17:25 but I would like to have comments from others ... adamw? 22:17:39 indeed. jlaska, ping 22:17:47 well, OK, when we push it to mirros (and say a "few days") 22:17:48 errr, too late 22:18:01 sorry 22:18:08 got distracted 22:18:10 OK, so the action item is that we should talk with these about better strategy? 22:18:11 what are we commenting on? 22:18:25 adamw: I'm trying to, err, make bodhi messages more useful 22:18:33 https://fedorahosted.org/fedora-infrastructure/ticket/701 22:18:42 last 20 minutes chat 22:19:05 * mcepl makes a cup of tea 22:19:11 fcami: yay 22:19:16 hehe :) 22:20:49 fcami: BTW, procedural complaint ... this is not much business of BugZappers. SHouldn't this whole be discussed by QA folks? 22:20:59 yeah, that too. 22:21:03 i agree with mcepl's original comments 22:21:10 not so much with 'omg we send three messages' - we kind of have to 22:21:23 why? 22:21:30 the only one we *could* skip is the submit-to-testing message (only send on push-to-testing) 22:21:40 but we definitely need both push-to-testing and push-to-stable messages 22:21:47 yes 22:21:51 the first to say 'hey, test this update' and the second to say 'hey, the bug's fixed' 22:22:00 i think the submit-to-testing has value, though, as it lets you get the fix asap 22:22:20 yes, sorry .. we definitively need two messages 22:22:28 if releng aren't pulling their fingers out, you could be waiting around two days for the push-to-testing notification, when the fix has been available from koji all along 22:22:42 push-to-testing and push-to-stable are valuable 22:22:52 http://fpaste.org/Nu0B/ 22:22:53 but yeah, submit-to-testing is the one we can drop if we want to drop one. 22:23:07 I am all for not bothering reporters with useless stuff 22:23:14 but this should be really discussed by QA folks 22:23:29 until bodhi has a better design, we could probably explain how to log in at bodhi before filing karma too 22:23:32 adamw, is there historically a delay between push-to-testing and submit-to-testing? 22:23:32 as that's my #1 bodhi faq 22:23:44 hmmm. adamw, when is the QA meeting? I think there is a reason I cannot be there :/ 22:23:55 fenrus02: other way around, and yes, there always is *some* delay. it should be max 24 hours (should be one push per day), but sometimes they get slack. 22:24:14 fcami: mondays at 8am PT, right now. 22:24:30 adamw, right, pesky RTL 22:24:31 adamw: that's yesterday 22:24:36 8am pt ... ught. 22:24:38 mcepl: yes it is. 22:24:41 ok 22:24:49 yeah, and that's definitely in the impossible world for me 22:25:15 adamw: I've been doing them every day for the last N weeks. ;) The only slack was one friday where bodhi went out to lunch and I had to do a bunch of things to get it pushing the next day. ;) 22:25:15 mcepl: tbh the reason I asked here is that I posted to test-list and never got feedback 22:25:19 fcami: you should probably ask adamw to be your ambassador 22:25:36 then 22:25:36 hmmm. that would work. :) 22:26:04 nirik: shut up while i slag you off! 22:26:13 :) 22:26:37 fcami: also it would make me look like i'm doing something, so i'm all for that! 22:26:45 rotfl. ok. 22:27:03 adamw: I'm going to submit a better version of the patch, and I'll CC you 22:27:12 OK, so it an #action then? 22:27:18 *is it an 22:27:30 for me yes 22:27:51 thanks a lot adamw :) 22:28:09 #action fcami through adamw sends https://fedorahosted.org/fedora-infrastructure/ticket/701 to QA folks to comment on 22:28:10 fcami: ok cool 22:28:17 anything else? 22:28:26 should we have open floor or is this enough? 22:29:13 I'm done. others? 22:29:33 three 22:29:35 two 22:29:37 one 22:29:40 #endmeeting