Summary
Hello everybody,
we just had our first BugSquad meeting and everybody was pleased with the results of our discussions. We had participants of teams like the Kubuntu team, the X Swat, the Desktop team, the MOTU Science team and newcomers who made the discussion diverse and produced good results.
- The first item on the agenda was about improving the current situation, this involved
- the current workflow,
- how to make the best out of the weeks before relase,
- how to make it easy for newcomers to get involved. While this sounds boring on first sight, Daniel Robitaille (who couldn't attend) made some statements to illustrate the situation [2], one of them was "we seem to be gaining ~100 open bug per week (9500 2 weeks ago, 9600 last week, 9727 tonight). We are fighting a losing battle it seems :)"
http://wiki.ubuntu.com/BugSquad/Observations
- A lot of proposals were made to remedy that.
Fabio di Nitto mentioned that it might make sense mass-close old bugs on certain dates and make it part of a "Release schedule" for the BugSquad. The "Release schedule" part of his suggestion was welcomed, but the general audience was more conservative about "mass closings". It was agreed that closing 'Needs Info' bugs which have no new input for three-four weeks can be closed with a nice response. [2]
- A lot of proposals were made to remedy that.
http://wiki.ubuntu.com/Bugs/Responses
Baishampayan Ghose had the idea of assigning 'Ubuntu' bugs (without a package) to the BugSquad, but the idea was rejected, since it was too much traffic and would probably have the same effect. The decision was taken to figure out a way to have a mailing list, where all the first posts of bugs without a package go. We are going to improve the list on the wiki [4] where the most prominent maintainer teams are listed to ensure that this process becomes more fluent.
https://wiki.ubuntu.com/Bugs/Teams
Fabio identified the areas of work as following: 'new incoming bugs', 'bug triaging (UNCO & unassigned)' and 'old bug junk'. We decided to have 'themed' Hug Days meaning that we concentrate on something else every two two weeks. (Watch out for the next announce for HugDay on Friday!)
Another approach was discussed, namely to add a package for each section of the Bug Squad for each work and focus on it. The DesktopTeam section of the BugSquad might want to attack evolution, while the Kubuntu guys look at the amount of kdeedu and amarok bugs. From these bugs we could write reports and make sure we rotate over different packages every time.
We considered asking for a BugSquad mailing list, which was for discussion and organisation only and would be a point to start for BugSquad newcomers and to discuss general plans of action.
At the end of the meeting everybody was charged up with energy and determined to make the next UbuntuBugDay [5] a blast.
http://wiki.ubuntu.com/UbuntuBugDay
If you want to contribute in one of the easiest ways, start here: http://wiki.ubuntu.com/BugSquad
Have a nice day, the BugSquad
Log
05:00 dholbach Ok everybody... here we go! 05:00 dholbach This the first BugSquad meeting - welcome everybody! 05:00 MiserySalin hello ;-) 05:00 G0SUB hi! 05:00 dholbach What do you think about doing a very quick round of introducing and saying what we work on wrt bugs? === ogra waves his flyflap 05:00 jsgotangco do we have a ribbon cutting ceremony? 05:00 kagou hi 05:01 fabbione sure 05:01 dholbach I'm Daniel Holbach, work mostly on Desktop bugs, some accessibility bugs, some Universe bugs, assorted bugs of packages I maintain and now some Icon bugs as well... and some stuff I probably forgot === JBennett [n=chatzill@cpe-66-24-28-210.stny.res.rr.com] has joined #ubuntu-meeting 05:01 dholbach just write into the channel - we don't need an order yet :-) === ogra is OliverGrawert having nightmares about unreproducable screensaver bugs 05:02 fabbione I am your X God.. and your bugs are pestering my inbox... 05:02 fabbione eh whops 05:02 fabbione i meant 05:02 ogra (and i care about all edubuntu related breakage as well) === Lure is LukaRenko looking for Kubuntu laptop/wireless stuff bugs... 05:02 fabbione I am Fabio Di Nitto.. one of the X maintainer 05:02 fabbione i need help to triage bugs 05:03 G0SUB I am Baishampayan Ghose, I usually take a look at random Unconfirmed & Unassigned bugs. Would like to make sure there are zero untriaged bugs especially in MOTU-Science 05:03 jsgotangco I am Jerome Gotangco currently looking at some app specific bugs like Yelp, G-A-I, some desktop love like AbiWord and bluetooth and Daniel thinks its a good idea i subscribe to ubuntu-bugs === _mvo_ is Michael Vogt and maintains a bunch of desktop software + has a interesst in CJK bugfixes 05:03 Toadstool I'm Jrmie Corbier, a french newcomer in Ubuntu bug squashing world and I try to do my best to find bugs I can handle or triage === cmvo [n=cmvo@62.225.11.174] has joined #ubuntu-meeting 05:03 philbull Hi, I'm Phil Bull and I'm a community bug triager 05:04 lakin I am Lakin Wecker, from Calgary, Alberta and have found that bug-triage is the easiest way for me to give back to Ubuntu, and would love to have easier ways to help others get involved in the same way. 05:04 seb128 I am Sebastien Bacher and I try to keep Desktop bugs under control :) === seaLne is Kenny Duffus and does kubuntu triaging and testing === Pygi [n=mario@83-131-246-24.adsl.net.t-com.hr] has joined #ubuntu-meeting === slomo is Sebastian Drge and I stressed malone in the last time by bug triaging in all different areas ;) 05:04 kagou i'm Patrice Vetsel, a french newcomer too. And i'm too shy so i 'll just do my best on triage === jjesse [n=jjesse@mail.ftpb.com] has joined #ubuntu-meeting === fabbione hands the microphone to dholbach 05:06 dholbach (for the ones who just joined the channel: we had a quick introduction round... if you want to introduce yourself, just do so...) === zakame [n=zak@ubuntu/member/zakame] has joined #ubuntu-meeting 05:06 zakame hi all 05:06 dholbach I'm quite happy we have a diverse team around and hope we get some good stuff covered today 05:06 dholbach we have our agenda on https://wiki.ubuntu.com/BugSquad/Meeting === heno [n=henrik@henrik.gotadsl.co.uk] has joined #ubuntu-meeting 05:06 zakame heya dholbach 05:07 dholbach maybe it makes sense to start with the 2nd agenda point, as "getting the team on track" is more general than the next bug day 05:07 dholbach robitaille can't attend today, but he brought some nice interesting facts to illustrate the current situation 05:07 dholbach i'll just paste them 05:08 dholbach "we seem to be gaining ~100 open bug per week (9500 2 weeks ago, 9600 last week, 9727 tonight). We are fighting a losing battle it seems :)" 05:08 dholbach "over 2/3 of these open bugs are "unconfirmed". I think we should be doing better job at this. A lot of these bugs could probably be easily "confirmed"; often it is obvious from the comments that multiple people are seeing these bugs. Confirming a bug is a good way to show an unexperienced bug reporter that his/her bug report is valued. It's a lot better to do this than having a bug report that goes totally unanswered for months if not e 05:08 dholbach ver. So maybe we should put little bit more effort in confirming new and old bugs." 05:08 dholbach "In Debian's area of LP, there are nearly 3000 open bugs. The large majority of these bugs are actually closed from a long time ago; when bugzilla bugs were imported, the ubuntu task kept its bugzilla.u.c status, but if it was linked to debbugs it got an open debian task. These false-open-debian-upstreams bug show up in the list of subscribed bug reports of Ubuntu developpers. It would be nice to clean these up to remove the number of us 05:08 dholbach eless bug reports floating around. But it's a very long, boring, and with not a lot of rewards task." 05:09 dholbach I think that all of us who have to do with bugs longer than the last days know that robitaille's statements are only accurate. 05:09 jsgotangco ive seen a lot of wishlist entries that can be easily addressed though 05:09 dholbach Can we think of ideas to make the BugSquad's efforts make all our lifes easier? 05:09 dholbach jsgotangco: wishlist entries like what? and addressed how? 05:09 fabbione i think we should first divide working areas here 05:09 slomo regarding the unconfirmed bugs... i saw many unconfirmed bugs in the past too where there already was some discussion and more people having that problem. it seems people have some kind of fear to set a bug on confirmed :) 05:10 G0SUB I second the idea of making the bugsquad the default assignee of all ubuntu bugs without any package 05:10 philbull G0SUB: +1 05:10 fabbione G0SUB: i disagree.. it doesn't do any good 05:10 jsgotangco it'll also fill up mailboxes heh 05:10 dholbach G0SUB: you know that it's *a lot* of traffic and mails you'll get 05:10 fabbione unassigned or tons of bugs assigned to the same teams makes no difference 05:11 zakame does LP currently provide a grep-like tool for ploughing unconfirmed seemingly-duplicate bugs? 05:11 G0SUB well, how'd we get this done otherwise? 05:11 Toadstool we should encourage people to search for already existing bugs and confirm them instead of filing another duplicate one 05:11 ogra we should divide ubuntu-bugs@ into more sections ... 05:11 lakin fabbione: but we can't currently produce a list of bugs which are filed without a package, I'm not sure of any way to get to them .. so they end up just falling through the cracks for months on end. 05:11 dholbach I liked the idea of having a list where new bugs go, which are not assigned to a package. 05:11 fabbione lakin: unassigned does not mean without a package. a package entry is mandatory in the bug report 05:11 dholbach with new bugs, I mean only the first mail / first entry 05:12 G0SUB dholbach: that's also a plausible idea ... wrt having a list 05:12 lakin fabbione: no it's not. 05:12 Lure fabbione: many report with ubuntu package 05:12 lakin fabbione: and G0SUB was talking about those bugs _without_ a package. 05:12 dholbach fabbione: no, there are a hug lot of bugs against 'Ubuntu' 05:12 ogra dholbach, but asssigned ones or the ones with packages should show up elsewhere 05:12 fabbione oh craptastic 05:12 fabbione but i consider that as triaging 05:12 dholbach ogra: what do you mean? 05:12 ogra <dholbach> I liked the idea of having a list where new bugs go, which are not assigned to a package. 05:13 fabbione that's why i was saying we should identify the areas where we want to work 05:13 fabbione and later define the tools we need to accomplish that 05:13 Toadstool +1 05:13 heno I would actually like a 'package' for the WinFOSS stuff if possible, because those get filed right on the distro ATM, but should go to me 05:13 dholbach yes, that's a good idea, fabbione 05:13 zakame ok 05:13 fabbione ok let's take turns in talking 05:13 jsgotangco we currently have 4,400+ on unassigned 05:13 dholbach heno: you can create an upstream product 05:13 fabbione otherwise it will get too confusing 05:13 fabbione dholbach: do you want to lead the discussion? 05:13 heno dholbach: thanks, will do 05:13 dholbach Ok... let's get back to the work areas. 05:14 dholbach How can we ensure to make progress there? 05:14 fabbione let's identify them first 05:14 fabbione imho we have 2 areas to work on 05:14 fabbione make that 3 05:14 G0SUB our main problem is the bunch of UNCO & Unassigned bugs ... 05:14 fabbione - new incoming bugs 05:14 seaLne unassigned bugs aren't helped by you not being able to assign a bug when you create it 05:14 fabbione - bug triaging (UNCO & unassigned) 05:14 dholbach let fabbione speak out 05:15 fabbione - old bug junk 05:15 fabbione now... 05:15 fabbione the problem is to get over the back log of bugs 05:15 fabbione in the past i would have used a very simple but very effective way to get rid of crap 05:15 fabbione like: 05:16 fabbione - decide when it's time to reset the counter 05:16 fabbione - mass processing of bugs from whatever status to date X -> Fix Released 05:16 fabbione - ask politely the submitters to reopen bugs that are still there 05:17 fabbione this process would "kill" old bugs backlog easily 05:17 fabbione but 05:17 fabbione we can't batch process in malone to do it === lakin raises his hand === jsgotangco raises hand 05:17 fabbione so we need to find a similar method to do it now 05:17 fabbione once that's done 05:17 fabbione the team can and should focus on 2 areas only 05:17 ogra the mail interface isnt scriptable ? 05:17 dholbach lakin, jsgotangco? 05:17 fabbione a few people could just look at new bugs 05:18 fabbione and make reassing them to the appropriate package 05:18 jsgotangco do we assume an old bug (say bug ID 3045) is fixed because we uploaded a new version? 05:18 zakame +1 05:18 fabbione another few people can look at what's left to see if it is assigned to the proper bugs 05:18 fabbione in this way we can clean up a lot of junk 05:18 fabbione and i truely mean a lot 05:18 dholbach fabbione: what do you propose? teams for these bug areas regardless of desktop/kernel/x/kubuntu/universe/.. 05:18 lakin With the fact that previous releases of Ubuntu are supported for X number of years, how can we close bugs with "fix released" when they still exist in an old release, and it's only been fixed in a new release? === vuntz_ [n=vuntz@volin.imag.fr] has joined #ubuntu-meeting 05:19 jjesse +1 lakin 05:19 seb128 yeah, you open a "backport task" if you want a fix backported 05:19 seb128 you don't keep the "normal task" 05:19 Lure lakin: +1, we need to separate bugs to releases - and it should be easy 05:19 seb128 that's on the right frame 05:19 dholbach yes, we should make more use of that. 05:19 fabbione dholbach: teams can form later on.. as soon as we get rid of the backlog 05:19 ogra Lure, then we'll never close most of them 05:19 fabbione dholbach: it is also natural for a person to look at bugs that are in his area of interest 05:19 dholbach fabbione: I think your proposal makes perfect sense for NeedsInfo bugs, which are open and unanswered for say 3-4 weeks 05:19 G0SUB fabbione: IMO, we can only close warty bugs like that 05:20 fabbione G0SUB: no, you can close easy hoary and breezy too. 05:20 seb128 bugs should be closed when fixed with current package, if a fix is worth backporting a backport task should be open 05:20 ogra seb128, ++ 05:20 dholbach fabbione: so you propose kind of a "release schedule" for the bug team? 05:20 fabbione what we really really really care is that if the bug is still present or not in the development release 05:20 slomo seb128: ++ === highvoltage [n=Jono@196.36.161.235] has joined #ubuntu-meeting 05:20 fabbione dholbach: sort of.. yes 05:20 fabbione for the stable releases, it is nice to know if the bugs are there 05:21 fabbione but we can rarely fix them 05:21 fabbione since almost none of them are of so high severity impact to require a -update 05:21 dholbach seb128: what do you think about fabbione's proposal? 05:22 seb128 is that basically "let's close all the deprecated bugs now"? 05:22 fabbione ogra: scripting the email interface is partially possible, assuming you have passphrase-less gpg key === lakin raises his hand again. 05:22 G0SUB how do we know which ones are deprecated? 05:22 dholbach lakin: go ahead 05:22 fabbione G0SUB: see above: -set date X 05:22 G0SUB okay 05:22 fabbione you do it arbitrary.. like 3 months ago 05:22 fabbione or something we agree upon 05:22 G0SUB fine, I like the idea 05:22 seb128 usual practice is to close "Needs Infos" bug after some weeks without a reply 05:23 slomo but only bugs that had no activity since then, yes? 05:23 lakin Sure, no one single bug might be serious enough for an update, but for some packages, having 10 of these fixes should qualify as serious enough for an update IMHO. 05:23 seb128 but we can't close unconfirmed bugs like that 05:23 MiserySalin by the way... does someone will write a summary of this decisions? For new members to read it for what to do in this situations === Blippe [n=henryson@1-1-11-41a.f.sth.bostream.se] has joined #ubuntu-meeting 05:23 dholbach I like seb128's proposal too 05:23 dholbach MiserySalin: I step up to do this 05:23 MiserySalin ah ok... thanks 05:23 fabbione seb128: the problems with your approach are: 05:23 G0SUB MiserySalin: a summary will be written 05:23 fabbione - the submitter might have provided info, the maintainer didn't check 05:23 MiserySalin Because I will forgot the half :-D 05:24 fabbione - most of the bugs are in Uncorfimed state 05:24 ogra cant we ask the launchpadders for such a feature (closing needinfo bugs automatically after some time 05:24 fabbione in this way you apply a "filter" that will help us almost >< this much 05:24 ogra ) 05:24 seb128 fabbione: my approach ensure I'm not frustating anybody by closing a bug that it took care to file and than nobody bothered commenting on 05:24 Lure fabbione: your proposal is to clean back log only now (once), but then later appliy the rule only to needs info? 05:24 vuntz_ ogra: would be nice 05:24 fabbione seb128: that is why i underlined to politely ask to reopen if it is still true 05:25 seb128 fabbione: sure 05:25 fabbione Lure: clean the backlog is a one operation only. It does not get repeated 05:25 fabbione the moment in which you clean the backlog, you MUST have the team in place to do the assigned task 05:25 Toadstool fabbione: once the bug is set to Needs Info, if someone adds a commentary the close timer could be reset too... 05:25 fabbione as i mentioned above 05:25 Lure fabbione: then we need to ensure that we do not get in similar situation again... 05:25 dholbach I agree with seb128 here. His proposal requires more work, but it ensures that we don't tread on anyone's toes... if we take great care of setting bug statuses, the NeedInfo state should be effective enough for such closing of bugs 05:25 seb128 fabbione: maybe malone should automatically reopen on new comment so bugs don't stay to Needs Infos (I say that but I hated that when GNOME did it) 05:26 dholbach lakin: you wanted to say something 05:26 fabbione seb128: i don't want malone to do anything, because it doesn't even have the basic tools to do what i am proposing 05:26 lakin Sure, no one single bug might be serious enough for an update for old releases, but for some packages, having 10 of these fixes should qualify as serious enough for an update IMHO. 05:26 fabbione seb128: like masschanging bugs 05:26 seb128 it has 05:27 slomo fabbione: you can masschange bugs 05:27 fabbione lakin: 10 small fixes don't make one serious 05:27 Lure seb128: how? 05:27 seb128 fabbione: do we have an xmlrpc interface yet? 05:27 fabbione slomo: no last time i checked.. like 2 days ago 05:27 fabbione seb128: no idea... 05:27 dholbach Ok... can we think of, what might be reasonable for the moment? 05:27 slomo fabbione: see https://wiki.launchpad.canonical.com/MaloneEmailInterfaceUserDoc#head-7e93c0730c2a71e7f7bccfbf0c3382b6adc962a5 05:27 seb128 fabbione: anyway you can do a script and mail 05:27 slomo fabbione: but that isn't of much use for us here imho 05:27 fabbione slomo: yes i know the email interface, there are other practical issues :) 05:28 lakin not to mention that there might be local companies that provide support and/or fixes for non-development branches of ubuntu on a per fee basis that might want to track this stuff in launchpad. I just can't accept that when something is fixed in the development release, that we should ignore it for older releases. 05:28 fabbione i discussed this exact problems 2 days ago with SteveA 05:28 dholbach lakin: some fixes are not suitable for backporting, like stuff that requires libary updates, or new upstream vresions 05:28 seb128 we can get launchpad guys making default "lists" matching what we need easily 05:28 fabbione lakin: if you have a better proposal, please speak 05:28 lakin That is, until the release reaches the unsupported state. 05:28 dholbach lakin: -updates fixes need to be *very precise and focussed* 05:29 seb128 let's not discuss what is backport material now 05:29 ogra and well tested 05:29 fabbione lakin: otherwise we need to create a team big enough to handle all of it 05:29 seb128 it's rather maintainer decision anyway 05:29 dholbach yes 05:29 lakin I'm not suggesting that we start trying to fix it, just that we keep track of where the bug exists in older releases, but we can discuss this later. 05:29 dholbach ok... which lists and reports would help us much to assign them to the bug squad team? 05:29 seb128 lakin: open a backport task 05:30 lakin seb128: k 05:30 dholbach "needsinfo, 3-4 weeks no info" was already mentioned 05:30 seb128 there is an option to the right frame 05:30 dholbach what else can we think of? 05:30 philbull no replies? 05:30 jsgotangco yes 05:30 philbull these are usually quick to triage 05:30 philbull *usually* 05:30 lakin list of bugs which have no package 05:30 seb128 "no package"? ie: assigned to "Ubuntu"? 05:31 dholbach lakin: these are a lot, but I agree, it would make much sense 05:31 seb128 we already have that 05:31 lakin err, yes, filed against "ubuntu" 05:31 fabbione - let 's assign a person or two to that? 05:31 lakin we do? where? 05:31 fabbione so that we can start having them reassinged to at least the proper team? 05:31 Toadstool lakin: with advanced search in malone maybe 05:32 seb128 lakin: hum, in fact no, but that's just a wishlist for malone 05:32 lakin seb128: yeah, I've filed a bug against malone for it. 05:33 dholbach if we could set up a mailfilter for a new mailing list that'd be great "bug against Ubuntu, first bug post" 05:33 jsgotangco that would be nice 05:33 G0SUB I like the mailing list idea 05:33 dholbach i'll ask around, how we could achieve that 05:33 seb128 lakin: number? === tormod [n=tormod@138.131.146.155] has left #ubuntu-meeting ["Ex-Chat"] 05:34 dholbach ok these two points would be easy for newcomers 05:34 dholbach and they surely would clean up malone 05:34 dholbach how do we approach the 6895 unconfirmed bugs? 05:34 lakin seb128, 35075 05:35 zakame one bug at a time 05:35 philbull dholbach: package at a time 05:35 G0SUB philbull: if there is no package? 05:35 zakame out of that 6k or so bugs a quarter or a half of those may be dupes 05:35 philbull hmmm 05:35 dholbach I'm going to announce bug days every two weeks - friday will be the next one... if teams are to propose 'packages to triage' that'll be fine 05:35 lakin One problem with approaching the unconfirmed bugs are that there are quite a few older bugs which have an unconfirmed status, but which have been: assigned properly, commented on by developers, and are even in the midst of being fixed ... we need ubuntu developers to keep up with their bug lists like seb128 does. 05:36 jsgotangco could we like focus on specific packages for some hug days 05:36 jsgotangco like desktop-bugs in 2 weeks 05:36 G0SUB jsgotangco: ++ 05:36 seb128 there is an import bug which hurts for that 05:36 philbull what are the packages with most bugs against them? 05:36 seb128 all the "UPSTREAM" bugs have been imported as "unconfirmed" 05:36 dholbach philbull: nautilus, evolution 05:36 philbull but do we have an exact list? 05:36 G0SUB ugh! 05:37 dholbach (on the Desktop side) === sladen is late. He's also Paul Sladen. 05:37 Lure philbull: would be good to have top list by package 05:37 lakin I started to go through them, but felt like I might be stepping on developers toes ... and I admit, all I was doing was confirming them. What's the approach we should take with them? 05:37 philbull b.g.o has this 05:37 dholbach https://launchpad.net/people/desktop-bugs/+packagebugs 05:38 philbull http://bugzilla.gnome.org/page.cgi?id=reports.html 05:38 dholbach lakin: that's something every bug triager has to live with, you *might* step on somebody's toes, but mostly you learn by it :-) 05:38 jsgotangco the worse thing you'll get is that it gets rejected 05:39 lakin dholbach: I know, but when you're working through a list of bugs, and _every_ bug makes you feel like you're doing this, it makes it tough to motivate yourself to continue. 05:39 seb128 lakin: you don't go on anybody else toes if you don't edit the same bug at the same time which is not really likely === lakin needs thicker skin, apparently 05:39 seb128 lakin: best way to not steep on the toes of anybody, pick the bugs older than a week 05:40 seb128 you can assume you don't "jump" on the bug before the maintainer has a chance to comment so 05:40 irvin and asking around #ubuntu-motu and #ubuntu-devel does help 05:40 dholbach i like the "by package" approach, if we would send out the BugSquad News (hi vuntz!), we could link to the packages we'Re about to check and which ones we cleaned already 05:40 seb128 lakin: I've pinged bradb about #35075 he will try to get it fixed for next launchpad update 05:40 dholbach and #ubuntu-bugs === buga [n=burjang@csomalin.csoma.elte.hu] has joined #ubuntu-meeting 05:41 lakin seb128: ++ 05:41 lakin :) 05:41 dholbach so now we have three things which will hopefully make life easier: 1) old-needs-info-cleaning, 2) new-ubuntu-bugs-triaging and 3) by-package-cleanup 05:41 jsgotangco i like the package group approach 05:42 dholbach jsgotangco: what do you mean by package group? 05:42 jsgotangco like for a certain time frame do triage on desktop === kagou [n=kagou@88-136-30-253.adslgp.cegetel.net] has joined #ubuntu-meeting 05:42 jsgotangco the move to a new set after that 05:43 G0SUB yeah, that's a good idea IMO 05:43 philbull i'm worried that those groups are too big 05:43 G0SUB like we declare that in the next HUG day we take a look at desktop-bugs 05:43 slomo philbull: dito... we should use smaller groups of packages... 05:43 slomo not something as big as desktop 05:43 dholbach jsgotangco: I'm not quite sure that Kubuntu people will have much patience with that... e.g: assign bugs to panel/applets, nautilus/gnomevfs, etc - they most likely won't be able to test bugs proplery 05:43 jsgotangco well evolution alone has tons 05:43 G0SUB hehe 05:44 dholbach What I'm trying to say is that people have areas, where they're good at 05:44 dholbach so "triage what you know/work with" might be a good mantra to get started 05:44 seb128 better if people work on what they are interested 05:44 dholbach jsgotangco: does that make sense? or isn't this what you meant? 05:44 jsgotangco well it does make sense to me 05:44 jsgotangco i focus on certain apps 05:45 jsgotangco instead of tackling the whole Unassigned bit 05:45 jsgotangco it can be overwhelming even for a team 05:45 dholbach yeah 05:45 jjesse i do as well, ij ust try to focus on the little things that i can help with 05:46 lakin I think if we get a nice set of reports of bugs that the ubuntu-bug squad is responsible for, and have a way to split these reports up by packages, or sets of packages, it will be easy to get a list that each person feels comfortable working through. 05:46 jsgotangco i just notice that there are active bugs out there with lots of comments but people are afraid to at least change the status to needs info or confirmed 05:46 dholbach so if we would start wiki pages with what set we're currently working on, say kubuntu team does kdeedu and kdebase and desktop team does nautilus and gnomevfs for a week and we send a report to the maiing list it'd be great to show we're actually moving something 05:46 jsgotangco even if there's like 5+ conversations going 05:46 jjesse agreed jsgotangco 05:47 Lure jsgotangco: +1 05:47 G0SUB dholbach: +1 05:47 dholbach I feel that we move step by step and people will accept the idea of bug statuses more and more 05:48 dholbach do you think that with the ideas we had, it's easy enough for newcomers to begin? 05:48 zakame dholbach: +1 05:48 dholbach maybe some of the new guys in here can speak up and tell us about their experiences 05:48 Toadstool dholbach: +1 05:48 ogra dholbach, apart from kdeedu being part of edubuntu +1 as well :) 05:48 philbull the documentation for triaging needs to be more explicit 05:49 dholbach who starts BugSquad/DocumentationTODO on the wiki? 05:50 philbull I just did 05:50 dholbach so if we had better documentation and tell them: "this week'S bugs are gnome-system-tools, gnome-utils and gthumb" will make it easy for them? 05:50 philbull easier...not easy 05:50 dholbach (if they're interested in the Desktop end of bug triage) 05:50 G0SUB It might 05:51 seb128 should we have a list to discuss bugs on? 05:51 philbull there are things that need to be explained 05:51 dholbach What else is missing? 05:51 dholbach is the coverage on #ubuntu-bugs good enough? 05:51 philbull well, I had real problems deciding who to assign things to 05:51 philbull #ubuntu-bugs is good, yeah :) 05:51 dholbach oh yes... a "team list" might be useful, with explanations of what they do 05:52 seb128 the issue is that "they"(== launchpad team) don't want to do default assignee 05:52 seb128 the workflow is supposed people are subscribed to a bug 05:52 ogra meh 05:52 dholbach seb128: we just shouldn't name it ...-bugs@, so people start reporting bugs there ;) 05:52 seb128 and you take the assignment only when you start working on something 05:53 dholbach and I think that's a good idea 05:53 Toadstool a bigger disclaimer about duplicates on the "report a bug" page and a smarter search engine would also make things a little easier to my mind 05:53 dholbach so it's more a matter of subscribing then assigning 05:53 dholbach Toadstool: the duplicates thing is filed as well 05:53 dholbach Toadstool: but I agree it's needed 05:53 dholbach back to the "team's list" 05:54 dholbach for "Ubuntu" bugs, it makes sense 05:54 ogra and the search engine is constantly beiong worked on ... 05:54 ogra it will improve over time 05:54 dholbach "this might be an X problem, who do I subscribe to get input?" is a valid question 05:54 dholbach ok, now we all know that fabbione is the X god, but still... some people might not know yet :) 05:55 zakame dholbach: heh I just asked that question some time ago === jsgotangco prays to X god to fix those x bugs === harisund [n=harisund@ip24-255-87-152.br.br.cox.net] has joined #ubuntu-meeting 05:55 fabbione jsgotangco: i am in really urgent need of help triaging bugs === harisund [n=harisund@ip24-255-87-152.br.br.cox.net] has left #ubuntu-meeting [] 05:55 fabbione i just can't get anywork done with 500 bugs of backlog === jsgotangco starts looking at xorg 05:55 lakin after some of the recent mailing lists discussions I made this page (https://wiki.ubuntu.com/HelpingBugReporters) which got a bit of traffic. the comments by AndreasSchildibach and FrancoisDenisGonthier might be appropriate for this meeting? 05:56 fabbione jsgotangco: wanna team up for that? 05:56 fabbione jsgotangco: i am not asking you to fix.. just to triage 05:56 jsgotangco sure 05:56 G0SUB fabbione: I am willing 05:56 jsgotangco any particular package? 05:56 zakame fabbione: me too 05:56 fabbione ok.. if you guys are volunteering.. let's take it after the meeting 05:56 G0SUB ok 05:56 fabbione i will give you hints on how to start 05:57 jsgotangco cool 05:57 dholbach (I hope everybody signed up for http://launchpad.net/people/bugsquad already) 05:57 dholbach what about seb128's idea of a bugsquad mailing list? 05:58 fabbione dholbach: we are already on 20000 ml 05:58 fabbione we should keep this process slim and fast 05:58 jsgotangco lol 05:58 fabbione i am not sure YAML will help here 05:58 dholbach fabbione: new triagers might not be and some are not on IRC all day 05:58 dholbach it's just a question at the moment 05:58 ogra fabbione, dont argue with dholbach about mailing lists ... youre surely loose in the end :P 05:58 zakame haha 05:58 Toadstool :) 05:58 dholbach ogra: pffft 05:58 G0SUB YAML? Yet Another Mailing List ? (wasn't it YAML Ain't a Markup Language?) 05:59 fabbione dholbach: if we are going to use the ml for discussion i am ok... 05:59 ogra thats how he always starts ... "<dholbach> it's just a question at the moment" 05:59 seb128 the issue is to have a place out of IRC where people can ask about whatever is an issue for them 05:59 fabbione but if it will become a duplicate of ubuntu-bugs, it's pointless 05:59 ogra :) 05:59 seb128 like they are not sure of where to assign stuff, or how to start or what to do about a bug 05:59 dholbach fabbione: i 100%ly agree 05:59 jsgotangco i'd go for organizational stuff 05:59 dholbach i like the idea too 05:59 fabbione dholbach: ok 05:59 seb128 not a list to sends all the bugs we get 05:59 ogra fabbione, ubuntu-bugs is only an auto importer for malone, isnt it ? 05:59 fabbione ok.. works for me 05:59 kagou seb128: i agree 06:00 dholbach cool 06:00 ogra s/for/from/ 06:00 dholbach so how do we make the next hug day a blast? 06:00 fabbione dholbach: kill all bugs? :D 06:00 dholbach apart from filing detailed descriptions of what to work on (on the wiki), improving our documentation? 06:00 zakame uhh, finding people who will make the hug day a blast =) 06:00 dholbach everybody of us paints a picture of bugs and we blog it to link to the hug day announce? :-) 06:00 kagou fabbione: how ? do you have a black hole ? 06:00 fabbione dholbach: ime the major issue is the "burocracy" behind working on bug.. we need to make the process slim 06:01 fabbione kagou: you have one too.. /dev/null 06:01 dholbach fabbione: bureaucracy like what? 06:01 ogra dholbach, using malone 06:01 G0SUB heh 06:01 fabbione dholbach: like people asking what they should work on, how to do it.. etc.. they should just do in a perfect world :) 06:01 lakin Is one of the improved documentation items going to be lists of searches that produce bugs of a certain triage-status along with links to the standard responses to those types of bugs? (Could help new members feel more comfortable about the first sets of bugs that they triage)? 06:01 dholbach ogra: if you can't depict the picture a bit clearer, we're unable to discuss it 06:01 zakame hmm, speaking of getting slimmer, does the new reportbug work on LP? 06:01 dholbach fabbione: right === _mvo_ [n=egon@p54A6642A.dip.t-dialin.net] has joined #ubuntu-meeting 06:02 dholbach zakame: no 06:02 dholbach lakin: that's a brilliant idea 06:02 ogra dholbach, the malone workflow is horrible compared to bugzilla ... i wont argue about that here, since it will improve ... but its a major slowdown ... 06:02 dholbach lakin: we should take that maybe to #ubuntu-bugs later on 06:02 lakin ok 06:02 seb128 GNOME guys do a "theme list" for every bug day 06:03 seb128 like "previous cycle bugs" to triage 06:03 ogra dholbach, nothing to discuss, just a statement ... 06:03 G0SUB ogra: it's just a PITA (malone) 06:03 seb128 or "new unconfirmed" 06:03 fabbione seb128: ++ 06:03 seb128 we could do some theme day 06:03 Toadstool that's a great idea 06:03 seb128 "multimedia bugs" day 06:03 ogra G0SUB, it will improve 06:03 dholbach cool 06:03 dholbach apart from that... I was serious about the PR machinery for the next hug day, how do we do it? :-) 06:03 slomo seb128: that's a very very very good idea ;) 06:03 G0SUB ogra: I hope it does ... 06:03 fabbione hmmmmm 06:03 fabbione seb128: the idea of theme is good, but we have one issue... 06:03 lakin I prefer themes days to asking for certain packages to be done on a specific hug-day. Everyone works on that theme within the sets of packages they feel comfortable with. 06:04 fabbione let say it's "X hugs day" 06:04 fabbione am I expected to be around 36 hours for coverage? 06:04 dholbach we made it UTC times the last time, so just 24h 06:04 fabbione well 06:05 dholbach https://wiki.ubuntu.com/UbuntuBugDay/Attending 06:05 fabbione i am still not capable of working 24 hours in a raw on X 06:05 fabbione given i am almost the only one working on it 06:05 dholbach what do you all think about giving fabio a hand on next hug day? 06:05 fabbione dholbach: when is that? 06:06 dholbach friday 06:06 fabbione *shrug* 06:06 fabbione ok let's talk about time and life 06:06 fabbione first lesson: 06:06 G0SUB let's make the next one `X HUG Day' 06:06 fabbione - there is a life out there... and it's not made of little greeen men 06:06 ogra pffft 06:06 G0SUB heh 06:06 ogra thats what yopur *wife* tells you ! 06:06 fabbione ogra: yes! 06:07 fabbione ok... 06:07 fabbione anyway 06:07 ogra dont belive her !! 06:07 fabbione let's try it on friday 06:07 fabbione but i won't be able to cover more than 10/12 hours 06:07 lakin Until we get a bug-reporter application (like discussed on ubuntu-devel) which can automatically gather various information from the machine before reporting the bug, could we ask the developers to edit a certain wiki pages with default information that is needed for certain packages. So we can start the process of gathering extra information for the bug-reports? 06:07 dholbach lakin: DebuggingProcedures 06:07 dholbach but it needs love for sure 06:08 dholbach we should put it on a big todo list too 06:08 lakin ok. 06:08 dholbach and we should send out detailed minutes of the meeting so everybody knows what we work on/worked on 06:08 Toadstool yeah well I think that's one of the point we should work on, improve WiKi pages about debugging 06:08 G0SUB goody :) 06:08 fabbione dholbach: time.. we are at 68 minutes 06:09 fabbione dholbach: i suggest a break or to stop 06:09 dholbach i want to finish with sladen's questions 06:09 fabbione ok 06:09 dholbach and take the rest to #ubuntu-bugs 06:09 dholbach where I hope you all hang out from now on 06:09 sladen lakin: we sort-of have the hwdb, but can't get any data back out of that 06:09 dholbach sladen had some questions as well, to answer some of them: point 1) what is the problem exactly? point 2) this would mean a bug report on Malone, no? 3) yes, it's a leftover, which will hopefully/perhaps be reactivated 06:10 ogra sladen, sure you can ... you can download the speciofic dataset and read it in vi ... 06:10 dholbach I will try to take care of the mailing list and all other stuff we covered, but I'll need you help for some of them, but let's take that to #ubuntu-bugs 06:11 jsgotangco ogra: open up 20GB in vi? :D 06:11 ogra jsgotangco, one dataset is ~240k 06:11 dholbach We should have a meeting again, after we see how our efforts emerge, but maybe we can discuss this on our fresh mailing list, when we have it. 06:11 sladen dholbach: We should document somewhere that we don't fix non-security bugs in released versions (and can point users at that page) 06:11 ogra the whole db is 5G currently ... (~220000 entries) 06:12 sladen dholbach: could do with a Unconfirmed Needs Info and an Confirmed Needs Info 06:12 dholbach sladen: we should add it to http://wiki.ubuntu.com/Bugs/Responses 06:12 dholbach sladen: that should be discussed with the Launchheads, no? 06:12 ogra sladen, the concept will change a bit for the 3/5y supported reelases 06:12 sladen dholbach: and (3), Debzilla should die and isn't actually related to debbugs 06:12 seb128 sorry I was away a few min 06:12 dholbach sladen: that's not something we as a bugsquad have to decided 06:12 dholbach decide === sladen happy. done. 06:13 dholbach I want to thank you all for being here and trying to make the best out of the bug situation. I think this was a very productive meeting. 06:13 G0SUB :) 06:13 dholbach Thank you all!