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.

  1. 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 :)"
  2. 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]

  3. 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.

  4. 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.

  5. http://wiki.ubuntu.com/UbuntuBugDay

Have a nice day, the BugSquad


   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@] 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@] 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@] 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
   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!


MeetingLogs/BugSquadTeam_2006-03-27 (last edited 2008-08-06 16:35:54 by localhost)