[01:06] <asac> hello
[01:15] <dfarning> asac hey
[01:17] <dfarning> jhnjwng how are you?
[01:18] <jhnjwng> good, got your email, let me know what I should do to join the team.
[01:18] <asac> dfarning: you want to setup some clue files for bughelper? I haven't used it so far ... what can we do?
[01:18] <dfarning> cool is there an area you are interested in
[01:19] <dfarning> asac I haven't used it either.  I spent much of the afternoon managling the bug mail;(
[01:20] <jhnjwng> I'd like to start with general bug triage. also interested in jvm related stuff.
[01:20] <asac> hehe ... yeah some activity lately :)
[01:21] <dfarning> jhnjwng meet asac
[01:21] <dfarning> asac meet jhnjwng
[01:21] <jhnjwng> hi asac.how r u.
[01:22] <dfarning> asac is our new developer and jhnjwng is interested in joinin the team
[01:22] <asac> jhnjwng: hello hello ... to start bug triage there are quite some options :)
[01:22] <dfarning> are you familaer with triaging
[01:23] <jhnjwng> I just started learning.
[01:23] <jhnjwng> I have read the document and  triaged couple,
[01:24] <dfarning> Just jump in by reading the mozillteam wiki
[01:24] <dfarning> some should be hear to answer any of your questions
[01:24] <dfarning> some one should be here
[01:24] <asac> a good thing is to subscribe to the bug system and follow how others process bugs
[01:25] <jhnjwng> I did watched for some time.
[01:26] <asac> gootd ... then there are lots of options ... getting initial info if bugs get post, trying to reproduce, trying to verify if there are already duplicates, trying to find upstream bugs (quite important)
[01:28] <jhnjwng> when you say upstream, do you mean bugzilla.mozilla.org?
[01:28] <asac> yes ... thats our main upstream bugtracker
[01:29] <dfarning> asac do you have a contact at mozilla?
[01:29] <asac> maybe important to know that we have to find a common understanding of how to use bug states and tags to better coordinate the workflow we need in order to process the quite huge amounts ob bug submissions we get
[01:29] <asac> dfarning: some ... what do you want?
[01:30] <asac> for the definition on how to use bug states and bug tags I started to setup wiki pages
[01:30] <jhnjwng> I also have a little of confusution of how workflow would be.
[01:30] <asac> rather incomplete :)
[01:30] <asac> dfarning: jump in if you disagree
[01:31] <dfarning> just following along;)  I've been gone for a while
[01:31] <jhnjwng> do we(or somebody) need to response to bug within 1 hour ?
[01:31] <asac> the idea is to allow people to select tasks as they like ...
[01:33] <asac> we try to categorize bugs in such a way that someone who has the will to help can go to the wiki page, read how he can get a list of bugs that need work which he finds suitable for the time and skills he can contribute
[01:33] <asac> a bug usually runs through the states we currently have in our bug tracker
[01:33] <dfarning> I would like to have a pretty short time for initial response
[01:34] <jhnjwng> Is there a coordinator that will dispatch the new bug to interested person?
[01:35] <asac> actually imo there should be some skilled team members that do the initial screening
[01:35] <jhnjwng> or we all need to look into it .
[01:35] <jhnjwng> that what I mean.
[01:35] <asac> and add tags so people can better see what bugs need what kind and skill of work
[01:35] <jhnjwng> sounds good to me.
[01:35] <asac> the initial categorization is maybe not the place to start for new comers ...
[01:36] <asac> its more the needs info state
[01:36] <asac> and the confirmed state where you can help
[01:36] <asac> the initial bug screener will add additional information to needs info ... currently we have
[01:36] <asac> only definitions for crashers
[01:36] <asac> needreport
[01:36] <asac> retrace (might go away)
[01:36] <asac> traced
[01:37] <asac> needreport is pretty simple ... people should look if the reporter already did submit a proper crash report ... and ping him from time to time
[01:37] <asac> as soon as proper crash report is attached he can set tag to retrace ...
[01:37] <asac> retrace (might go away, as this will hopefully automized)
[01:37] <asac> needs someone to download crash report
[01:38] <asac> and run a retrace on it, so we get a symbolized crash reports, that allows us to take a look what the crash is about
[01:39] <asac> if a bug is traced someone properly more skilled has to take a look if the trace is sufficient for further processing and then try to find duplicates based on the stacktrace
[01:39] <asac> if that is done the bug can go to confirmed state where all the actual bug evaluation and upstream triage will happen
[01:40] <asac> then if we know how to fix it on our own or we submitted upstream ... we go to "in progress" ... and so forth :)
[01:40] <asac> anyway, for bugs other than crashers we still have no procedure
[01:40] <dfarning> Got to go home for dinner I am looking forward to reading the log of this discussion
[01:41] <asac> yeah ... not much left.
[01:41] <asac> :)
[01:41] <asac> jhnjwng: hope that was not too much
[01:41] <asac> :)
[01:41] <jhnjwng> no, asac. thanks for the education.
[01:41] <asac> anyway ... now what you could do :)
[01:42] <asac> if you want to get started to the mechanisms ... you could go through the mozilla-thunderbird bugs
[01:42] <asac> :)
[01:42] <asac> and look for bugs that have a wrong debian upstream bug
[01:42] <asac> there should be quite a good bunch :)
[01:42] <asac> actually its always the same
[01:42] <asac> either the bug is right
[01:43] <asac> or the bug is wrong, because it was cloned upstream
[01:43] <asac> you can easily see this
[01:43] <asac> if we have a bug that has a debian upstream url
[01:43] <asac> and is in state fix released
[01:43] <asac> this is probably wrong
[01:43] <asac> :=
[01:43] <asac> you understood what I mean?
[01:44] <asac> https://bugs.launchpad.net/ubuntu/+source/mozilla-thunderbird/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=Unconfirmed&field.status%3Alist=Needs+Info&field.status%3Alist=Confirmed&field.status%3Alist=In+Progress&field.status%3Alist=Fix+Committed&assignee_option=any&field.assignee=&field.owner=&field.status_upstream=only_resolved_upstream&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.h
[01:44] <asac> that list might be the ones
[01:44] <asac> you can do that searc
[01:44] <jhnjwng> let me open it.
[01:44] <asac> by advanced search and then selecting the "bugs that are resolve upstream" radio button in the lower end
[01:46] <asac> https://bugs.launchpad.net/ubuntu/+source/mozilla-thunderbird/+bug/49478
[01:46] <asac> thats one example
[01:46] <Ubugtu> Malone bug 49478 in mozilla-thunderbird "thunderbird warning on installation (breezy)" [Low,Confirmed] 
[01:46] <asac> it has a debbugs upstream bug
[01:46] <asac> which is resolved
[01:46] <asac> if you look at the bug
[01:46] <asac> there is a message "Cloned bug xxx as xxxx" somehwere in it
[01:46] <asac> you would have to change the referend bug to the new one
[01:47] <asac> anyway, looks like that there are not so many :/ ... some of the list above are bugzilla bugs... those are properly right ... only debbugs are of interest
[01:47] <asac> :)
[01:48] <asac> there should be 3-4  such bugs
[01:50] <jhnjwng> I see the "cloned .." in debian bug system. so I will start with this one. I will let you know If I have problems.
[01:51] <jhnjwng> thanks again. have to goto dinner and will join a litter bit later.
[01:51] <asac> sure ... thx a lot ... we will definitly come up with more tags with better documentation how to perform that task so if you visit wiki and find something interesting, feel free to go ahead
[01:51] <asac> i will usually read bug mails and if you really do something wrong, I will let you know ... so just go ahead ;)
[01:51] <asac> learning by doing :)
[03:29] <gnomefreak> something needs to be worked out with the list. everytime someone comments on a bug its gonna ask us for aproval?
[03:48] <gnomefreak> hjmf: you have an edgy 64bit chroot?
[03:55] <hjmf> hi
[03:56] <gnomefreak> hi
[03:56] <hjmf> no i'm not, and I'm pretty sure that stacktrace (if you are asking for bug 82601) is notk ok
[03:56] <Ubugtu> Malone bug 82601 in firefox "Firfox shuts down occassionally when switching tabs or to open an URL in a new tab." [Undecided,Needs info]  https://launchpad.net/bugs/82601
[03:56] <gnomefreak> i think let me look
[03:57] <gnomefreak> that would be the one
[03:57] <hjmf> not sure, I was playing a bit.
[03:57] <gnomefreak> you got the symbols but i didnt think you could run 64bit retraces on 32bit but seeing as you got all symbols its strange to me
[03:58] <hjmf> I'm using the right deps, but on 32bit
[03:58] <gnomefreak> ah
[03:59] <hjmf> As I've said im playing, I'll keep that bug assigned to me until I'll be sure
[03:59] <gnomefreak> ok was just wondering if it was possible ;)
[04:00] <hjmf> Any how I've posted the stacktrace to get your feed back, Just beginnig to learn
[04:00] <hjmf> s/Any how/anyhow
[04:01] <gnomefreak> i have a few other questions for asac so i might ask him to check that stack to make sure its good | that way maybe i wont need another chroot to run 64s
[04:02] <hjmf> please do it :)
[04:02] <gnomefreak> this frigging mailing llist is gonna kill me today
[04:02] <hjmf> I'm leaving that issue for tomorrow (evolution is getting mad today) :(
[04:03] <gnomefreak> you would think you click remind me (of password it would send it to me :(
[04:26] <gnomefreak> i think i won :)
[04:54] <asac> gnomefreak: what?
[04:54] <asac> which stack? :)
[04:54] <asac> hello!
[04:54] <gnomefreak> hi
[04:54] <gnomefreak> ok let me find it
[04:55] <gnomefreak> bug 82601
[04:55] <Ubugtu> Malone bug 82601 in firefox "Firfox shuts down occassionally when switching tabs or to open an URL in a new tab." [Undecided,Needs info]  https://launchpad.net/bugs/82601
[04:55] <gnomefreak> that stack
[04:56] <gnomefreak> he used 32bit to debug 64bit and it looks good but wanted to cjeck with you
[04:56] <asac> yeah its good
[04:56] <asac> yet another theme switch bug :)
[04:56] <gnomefreak> cool :)
[04:56] <asac> apparently those happen not only if the you explicitly update theme
[04:56] <gnomefreak> asac: im thinking its related to flash
[04:57] <asac> might be that flash triggers restyling more often ... but the stack looks like restyling, aka retheme bug :)
[04:57] <gnomefreak> one of the bugs someone said he changed to flash 9 and it stopped crashing
[04:57] <asac> but if its traced I will take a closer look sure :)
[04:59] <gnomefreak> i will find out what he did to get that trace and try to see if i cant get it to work :)
[05:00] <asac> i don't think we have *no* flash crashes ... but I think that this one is not about flash :)
[05:00] <asac> which is the bug where he told us that using flash 9 fixes it?
[05:00] <asac> i saw that too, but can't remeber the bug number of course :)
[05:00] <gnomefreak> i will look for it tomorrow
[07:15] <asac> lets keep bugs in Needs Info state until we did a dupe hunt and have reviewed the trace (e.g. tag traced), ok?
[08:07] <gnomefreak> k