[01:53] <ToadZzZztool> @schedule Europe/Paris
[01:53] <Ubugtu> Schedule for Europe/Paris: 27 Mar 17:00: Bug Squad | 28 Mar 22:00: Technical Board | 29 Mar 14:00: Edubuntu | 30 Mar 04:00: Dapper Development Status | 30 Mar 14:00: Edubuntu Cookbook | 31 Mar 23:00: Documentation Team
[03:30] <bmonty> @schedule US/Central
[03:30] <Ubugtu> Schedule for US/Central: 27 Mar 09:00: Bug Squad | 28 Mar 14:00: Technical Board | 29 Mar 06:00: Edubuntu | 29 Mar 20:00: Dapper Development Status | 30 Mar 06:00: Edubuntu Cookbook | 31 Mar 15:00: Documentation Team
[03:30] <MarioMeyer> @topic
[03:31] <MarioMeyer> @schedule Brazil/East
[03:31] <Ubugtu> Schedule for Brazil/East: 27 Mar 12:00: Bug Squad | 28 Mar 17:00: Technical Board | 29 Mar 09:00: Edubuntu | 29 Mar 23:00: Dapper Development Status | 30 Mar 09:00: Edubuntu Cookbook | 31 Mar 18:00: Documentation Team
[09:02] <dholbach> good morning
[09:04] <JaneW> hello
[09:05] <dholbach> hey JaneW!
[09:05] <JaneW> odd, I am only connected to some of my ubuntu # (the rest are disconnected) ...?
[09:12] <simira> that is strange
[09:12] <simira> and I just read "Ubuntugeek" instead of "bergeek"
[09:15] <highvoltage> hi JaneW 
[09:15] <JaneW> hello highvoltage 
[09:33] <robitaille> @schedule US/Pacific
[09:33] <Ubugtu> Schedule for US/Pacific: 27 Mar 07:00: Bug Squad | 28 Mar 12:00: Technical Board | 29 Mar 04:00: Edubuntu | 29 Mar 18:00: Dapper Development Status | 30 Mar 04:00: Edubuntu Cookbook | 31 Mar 13:00: Documentation Team
[04:58] <dholbach> everybody get their snacks/tea/coffee/stuff ready? :-)
[04:58] <fabbione> yeah
[04:58] <lakin> close enough
[04:58] <fabbione> i had my 2 chicken sandwich with salad and fresh tomatos...
[04:58] <ogra> hrm
[04:58] <Toadstool> ready to go :)
[04:59] <jsgotangco> yeah
[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?
[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
[05:01] <dholbach> just write into the channel - we don't need an order yet :-)
[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)
[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
[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
[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 :)
[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 
[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...)
[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
[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?
 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
[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?
[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: ++
[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
[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
[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?
[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)
[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
[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
[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
[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
[05:55] <fabbione> jsgotangco: i am in really urgent need of help triaging bugs
[05:55] <fabbione> i just can't get anywork done with 500 bugs of backlog
[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
[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
[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!
[06:13] <G0SUB> cheers!
[06:13] <seb128> fabbione: you don't need to be here the whole day, some other people should have enough clue to triage basic xorg stuff (mark duplicates, figure if that's a driver issue, etc)
[06:14] <ogra> dholbach, thanks for leading us :)
[06:14] <zakame> thanks
[06:14] <philbull> thanks dholbach :)
[06:14] <Toadstool> thanks dholbach ^^
[06:14] <fabbione> ok guys
[06:14] <fabbione> for who would like to help with X triaging
[06:14] <dholbach> thanks
[06:14] <fabbione> i suggest we take a 5 minutes break
[06:15] <kagou> thanks dholbach
[06:15] <seb128> thank you dholbach
[06:15] <fabbione> and i will give some highlights on how to do it on #ubuntu-bugs
[06:15] <fabbione> does that work?
[06:15] <dholbach> fabbione: maybe we can add some stuff to http://wiki.ubuntu.com/DebuggingProcedures
[06:15] <seb128> fabbione: feel free to do a wiki page on the topic :)
[06:15] <fabbione> dholbach: there should be already a page for that
[06:16] <zakame> coolness!
[06:16] <lakin> thanks dholbach
[06:16] <fabbione> https://wiki.ubuntu.com/DebuggingXAutoconfiguration
[06:16] <fabbione> see
[06:17] <jsgotangco> ok
[06:17] <fabbione> ok be back in 5
[06:17] <zakame> oki
[07:38] <zakame> highvoltage: awww