=== Starting logfile irclogs/ubuntu-mozillateam.log
=== ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog]  has joined #ubuntu-mozillateam
=== Topic for #ubuntu-mozillateam: Home of Ubuntu Mozilla Team - https://wiki.ubuntu.com/MozillaTeam | Bug Triagers please read: https://wiki.ubuntu.com/MozillaTeam/Bugs/ | Firefox trunk package source : https://code.launchpad.net/~mozillateam/firefox/trunk | Mailing List: ubuntu-mozillateam@lists.ubuntu.com | Next Meeting, Monday August 20th at 20 UTC in #ubuntu-meeting
=== Topic (#ubuntu-mozillateam): set by Admiral_Chicago at Wed Aug 15 18:48:45 2007
=== shirish [n=shirish@59.95.29.150]  has joined #ubuntu-mozillateam
=== shirish [n=shirish@59.95.29.150]  has left #ubuntu-mozillateam ["Leaving."] 
=== JenFraggle [n=jen@91.84.43.217]  has joined #ubuntu-mozillateam
=== Ubulette is now known as _Ubulette
[01:15] <asac> bnovc: still here?
=== hjmf_ [n=hjmf@7.Red-83-44-173.dynamicIP.rima-tde.net]  has joined #ubuntu-mozillateam
=== asac [n=asac@e177174172.adsl.alicedsl.de]  has joined #ubuntu-mozillateam
=== tonyyarusso [n=anthony@ubuntu/member/tonyyarusso]  has joined #ubuntu-mozillateam
=== bnovc [n=bnovc@64.22.118.221]  has joined #ubuntu-mozillateam
=== _Ubulette [n=Ubulette@APuteaux-153-1-41-102.w82-124.abo.wanadoo.fr]  has joined #ubuntu-mozillateam
=== AlexLatchford [n=alex@82-44-193-109.cable.ubr07.haye.blueyonder.co.uk]  has joined #ubuntu-mozillateam
=== ubotu [n=ubotu@ubuntu/bot/ubotu]  has joined #ubuntu-mozillateam
=== Mirv [n=tajyrink@pdpc/supporter/active/Mirv]  has joined #ubuntu-mozillateam
=== Ubulette_ [n=Ubulette@APuteaux-153-1-19-57.w82-124.abo.wanadoo.fr]  has joined #ubuntu-mozillateam
=== Paddy_EIRE [n=patrick@89.240.251.170]  has joined #ubuntu-mozillateam
=== JenFraggle [n=jen@91.84.43.217]  has joined #ubuntu-mozillateam
[04:31] <bnovc> asac: i'm around now if you are
[04:32] <asac> bnovc: yes ... i am here ... but can only give this channel 5% atm
[04:32] <asac> bnovc: i read that you want to help ... thats great!
[04:32] <asac> bnovc: are you more a technical person or more a user?
[04:33] <bnovc> asac: probably technical
[04:33] <bnovc> that's what i'd prefer to help with
[04:34] <asac> ok one thing that everybody should do ... regardless of what his main work is ... is help a bit on bugs ;)
[04:35] <asac> we try to sort bugs out by tagging them so volunteers who look for a certain task can pick bugs from such a list
[04:36] <asac> you can read how the mozillateam sorts-out bugs in https://wiki.ubuntu.com/MozillaTeam/Bugs/States and https://wiki.ubuntu.com/MozillaTeam/Bugs/Tags ...
[04:36] <asac> the states page tries to be a bit verbose what is to do for each state
[04:36] <asac> while the tags page provides you with quick links to bugs of each state
[04:36] <asac> maybe take a look
[04:37] <bnovc> k
[04:39] <asac> in addition we have a list of bugs that were badly triaged (e.g. they are not properly tagged)
[04:39] <asac> those would need to be tagges properly ... because if bugs are not properly tagged they just slip through our workflow and might become forgotten et al
[04:41] <asac> bnovc: i think the wiki might be a bit outdated as launchpad renamed its state ... its mostly just "Needs Info" is now called "Incomplete" ... but it shouldn't matter ... whatever applied to Needs Info previously now applies to Incomplete
[04:42] <bnovc> 'triage' is an amusing name for bugs :)
[04:43] <bnovc> k, read through those pages
[04:46] <bnovc> i'm not sure i would know where to begin if i  just got the ff source and started trying to fix a bug though
[04:50] <bnovc> need to get going for a big, be back mid-afternoon
[04:56] <asac> bnovc: its not about fixing in the first place ... most bug triage work is about sorting things out :)
[04:56] <asac> only things that are in state Confirmed mt-eval needs to be evaluated how they can be fixed
[04:56] <asac> everything else just needs technical expertise to filter as much bugs to /dev/null as possible :-D
[04:57] <asac> bnovc: anyway ... if we run into a bug and i have an idea where in ff source the problem might stem from you can go and fix it ;)
=== Paddy_EIRE [n=patrick@89.240.251.170]  has joined #ubuntu-mozillateam
=== Mirv [n=tajyrink@vipunen.hut.fi]  has joined #ubuntu-mozillateam
=== Ubulette_ is now known as Ubulette
[07:45] <Ubulette> hi
=== Paddy_EIRE [n=patrick@89.240.251.170]  has joined #ubuntu-mozillateam
=== Jazzva [n=sasa@89.216.128.244]  has joined #ubuntu-mozillateam
[09:02] <Jazzva> Evening...
[09:08] <Ubulette> hi
[09:08] <Jazzva> How
[09:08] <Jazzva> How's the work going? (BTW, I hate the position of this Enter key)
[09:21] <Ubulette> "'" is on the 4 on my keyboard...
[09:22] <Ubulette> Jazzva, haven't much done for this group today.
[09:23] <Jazzva> I prefer to use the English layout if I don't need local characters :)... If I need them, then "'" is on the dash key...
[09:23] <Jazzva> BTW, asac, I won't be able to do anything big this week... Two exams coming this weekend...
[09:23] <Jazzva> Me neither, Ubulette... I promise I will next week O:)...
[09:24] <Jazzva> Well, off to studying... Have fun.
[09:25] <Ubulette> good luck :)
[09:25] <Jazzva> Thanks :)
[09:49] <asac> Jazzva|away: exams on weekend? wierd ... but good luck
[09:56] <Ubulette> hm, seems bug 123103 is fixed, at least in today's trunk
[09:56] <ubotu> Launchpad bug 123103 in firefox-granparadiso "Firefox Granparadiso changing workspace" [Low,New]  https://launchpad.net/bugs/123103
[09:58] <Jazzva|away> asac: Yeah... the worst time for exam is Sunday at 8am :)... Well, any day at 8am. Though I'm lucky: Saturday at 5pm... and Friday at 8am.
[09:59] <Ubulette> never had exams on sunday myself..
[09:59] <Ubulette> mozilla bug 335742
[09:59] <ubotu> Mozilla bug 335742 in General "Does not respect window manager policy - raising window" [Normal,Unconfirmed]  http://bugzilla.mozilla.org/show_bug.cgi?id=335742
[09:59] <Ubulette> hmm, seems too old
[10:04] <Ubulette> mozilla bug 388664
[10:04] <ubotu> Mozilla bug 388664 in OS Integration "opening link from another application raises/focuses/moves Firefox window" [Normal,New]  http://bugzilla.mozilla.org/show_bug.cgi?id=388664
[10:05] <Ubulette> more like it but no tagged as fixed.. strange
[10:13] <asac> whats the problem?
[10:13] <asac> e.g. what are you looking for?
[10:16] <Ubulette> see if it was fixed or if it's something else that fixed it
=== Mirv [n=tajyrink@vipunen.hut.fi]  has joined #ubuntu-mozillateam
[11:14] <Ubulette> asac, my lp login just changed, so have all my urls, bzr included
=== AlexLatchford [n=alex@82-44-193-109.cable.ubr07.haye.blueyonder.co.uk]  has joined #ubuntu-mozillateam
[12:03] <bnovc> asac: i see, well if you would like to give me some more guidance on what specifically i can do, i'll help out
[12:23] <asac> bnovc: cool ... maybe start with some simple ones ... look at the ones that are tagged mt-needtestcase ... verify if there is already a step by step instruction to reproduce in summary ... if not, try to extract one from the bug comments ... or ask submitter to provide more info
[12:23] <asac> bnovc: https://wiki.ubuntu.com/MozillaTeam/Bugs/Tags
[12:24] <asac> bnovc: further the ones that are tagged mt-needtester claim to have a step by step instructions, but we need someone with some technical expertise to verify that the bug can be reproduced that way
[12:24] <asac> bnovc: https://launchpad.net/ubuntu/+source/firefox/+bugs?field.tag=mt-needtester
[12:24] <asac> those are the ones that need a tester
[12:24] <asac> if you find that you can reproduce, ensure that the summary contains a clear step-by-step instruction and then change tag to mt-confirm
[12:25] <asac> or if you are confident that the testcase is really good ... set tag to mt-upstream and state confirmed
[12:25] <asac> (e.g. all mt-needtester and mt-needtestcase are state Incomplete)
[12:26] <asac> mt-upstream means that a triager should try to find an equivalent bug in bugzilla.mozilla.org ... which can be pretty hard
[12:27] <asac> if you want to vade through bugzilla.mozilla.org bug database you could also take a look at the other bugs that are tagged mt-upstream ... which basically means that we have to ensure that there is not already and upstream bug filed ... before we submit one and/or start to evaluate a solution
[12:28] <asac> if we think that the problem is more or less ubuntu related, we don't tag mt-upstream, but use mt-eval ... which means some skilled developer should try to evaluate a solution
[12:28] <asac> bnovc: is that enough to start with?
[12:28] <Jazzva|away> bnovc, asac, there is a beginners page on MozillaTeam that explains the bug testing :). Maybe that would be a good read...
[12:29] <asac> yes right
[12:29] <asac> the one by jenfraggle, right?
[12:29] <Jazzva|away> Mhm... Here's the link: https://wiki.ubuntu.com/MozillaTeam/Bugs/Beginner
[12:29] <asac> Jazzva|away: yeah right ... is that properly linked from some page?
[12:30] <Jazzva|away> bnovs, maybe you could go through it... It's mostly what asac said, but in more words :).
[12:30] <Jazzva|away> bnovc ^
[12:30] <Jazzva|away> Dunno... will check it now...
[12:30] <asac> Jazzva|away: yes ... its what i explained to jenfraggle once
[12:30] <asac> i think it should be linked from the procedures page ... and maybe from the main bugs page as well
[12:31] <asac> Jazzva|away: https://wiki.ubuntu.com/MozillaTeam/Bugs/Procedures .... in the initial paragraph there is already the transcript on which that beginner page is based on
[12:31] <asac> i think the begginner page should be linked from there as well
[12:32] <Jazzva|away> Well, I can't find the link on main bugs page... I'll put one
=== Jazzva|away needs a little break from studying...
[12:32] <asac> yeah .. already wondered what you are doing here ;)
[12:32] <Ubulette> asac, is debian packaging trunk ? (IceWeasel 3.0b or whatever)
[12:33] <asac> Jazzva|away: on the main bugs page there is just a tiny link on the bottom to the procedures
[12:33] <asac> Jazzva|away: we usually send users to that page ... so lets not fill it up with more triaging details
[12:33] <asac> but maybe expanding the procedures paragraph on that page might be beneficial ... i agree
[12:33] <Jazzva|away> Mmmhm... No prob.
[12:34] <asac> Jazzva|away: but the procedures page should definitly contain all ;)
[12:34] <asac> Ubulette: well debian is basically me and mike ;)
[12:34] <Jazzva|away> All, not just a link to Beginners page? :)
[12:34] <Jazzva|away> asac ^
[12:34] <asac> huh?
[12:35] <asac> sorry can't parse that ;)
[12:35] <asac> ah i see
[12:35] <asac> sorry
[12:35] <asac> of course links
[12:35] <asac> not the content ... but all links should be on the procedures page ;) ... thats what i ment
[12:35] <Jazzva> That's whay confused me :). Ok, I'll put link to the procedures page... :)
[12:35] <bnovc> i'll read through that beginner page
[12:35] <Ubulette> asac, i guessed so. that's why I ask you. reason was to know if they have the same ftbs on non-i386/amd64..
[12:36] <asac> bnovc: yeah ... and maybe the transcript ... as the beginners page is already filtered ;)
[12:36] <asac> bnovc: and might be not completely accurate ... more or less intentional for the sake of readability
[12:37] <asac> Ubulette: those build failures are almost certain the same
[12:37] <asac> Ubulette: currently we haven't uploaded any trunk builds to debian
[12:38] <Ubulette> asac, no plan to ?
[12:38] <asac> Ubulette: i talked to mike about this once ... and he seemed to be open to push the packages to experimental ... but with the same name
[12:38] <asac> e.g. iceweasel (not iceweasel-trunk)
[12:39] <Ubulette> what does that mean for us here ?
[12:40] <Ubulette> i was just about to drop trunk from nss and nspr as I want to package real trunks for those
[12:40] <asac> good question :) ... yes if he doesn't say no it would probablyb e that way
[12:41] <asac> i will talk to him next time i see him online
[12:41] <asac> he is usually online everyday ... but can leave out a day or two
[12:41] <Ubulette> k
[12:41] <asac> but i hope i get a grib on him tomorrow
[12:41] <asac> Ubulette: we are currently trying to move debian maintenance to a git repository
[12:41] <asac> e.g. with full source tree
[12:42] <asac> we already track the git tree here:
[12:42] <Ubulette> not sure including the source tree is a good idea
[12:42] <asac> http://git.debian.org/?p=pkg-mozilla/upstream.git;a=summary
[12:42] <Ubulette> yeah, i've been there
[12:42] <asac> since we maintain a fork its more or less a good thing
[12:43] <Jazzva> asac: Ok, added the link on the procedures page... Back to studying...
[12:43] <asac> but mostly we do all this because eric doesn't like patchsystems ... so we try to find a way that suites him, but still allows us to keep clean patches ... e.g. on top
[12:43] <Ubulette> seems a lot of commits upstream to sync
[12:43] <Jazzva> Have fun ;)...
[12:44] <asac> Ubulette: no we don't do that ... we just track regularly
[12:44] <asac> checkouts
[12:44] <asac> Ubulette: for us its more or less a good thing because we maintain the ice-* fork
[12:44] <Ubulette> oh, you co upstreamn then merge in one commit ?
[12:44] <asac> Ubulette: so the mozilla-1.8 branch tracks prinstin upstream checkout
[12:44] <asac> Ubulette: yes that works pretty well ... at least for rebasing
[12:44] <asac> which is what we want to keep our patches on top
[12:45] <Ubulette> who's eric ?
[12:45] <asac> the firefox/iceweasel maintainer (eric dorland)
[12:45] <asac> hw is currently not much active since he started working for google ... but he still has his stake in all this
[12:46] <asac> anyway ... another benefit we get is that we are currently working with gnuzilla people to consolidate the crap they do
[12:46] <asac> e.g. they should just use our ice-branch ... and maintain an extension to add their features
[12:46] <asac> the current situation is really confusing ... as they release iceweaasel ... which is differnt to what debian releases
[12:48] <asac> Ubulette: so to summarize the facts ... iceweasel will probably not get a patchsystem :/ ... and since we hate to do differnt things for all these packages we will drop patchsystems for icedove, iceape, xulrunner et al as well.
[12:49] <Ubulette> you mean drop debian/patches ?
[12:49] <asac> it was a hard decision, but eric stayed firm and for the matter of consitency mike and me agreed to try to go the git way ... mike is currently evaluating to be sure ... i am pretty sure that i works because i did that a long time for the 1.7 branch
[12:49] <asac> and still maintain feisty firefox that way
[12:50] <asac> Ubulette: yes ... but its not much different ... we have the patches on top and rebase ... so you can always export distinct patches
[12:51] <asac> the benefit is that people can more easily submit patches ... the backdraft is that we have to maintain this git branch
[12:52] <Ubulette> hmm. so that means no more sync with ubuntu, either way
[12:55] <asac> no idea :/ ... actually the sync is nearly non-existant atm
[12:55] <asac> so things can only improve
[12:55] <asac> and since git allows you to export those patches its not really harder
[12:57] <asac> our firefox package forked of the debian one at some point ... then it was modified by iwj before i came .. then i untangled the huge diff.gz into distinct patches (yeah ... what a pain)
[12:58] <asac> which i still maintain in git here ... then in gutsy i punched those patches into a patches directory
[12:58] <asac> for thunderbird its a bit better ... but even though i am the maintainer on both sides its pretty much out of sync atm
[12:59] <asac> however last icedove upload was resynched ... so its not that bad anymore
[01:02] <asac> Ubulette: anyway... nothing is set ... the git archive currently just tracks mozilla and the freed ice branch
[01:02] <asac> Ubulette: last time i talked to mike he confessed that he started to love using quilt ... so lets see
[01:03] <asac> Ubulette: hopefully i will get him tomorrow so i can sort these things out.
[01:04] <Ubulette> you converted me to quilt too.. yet the way it is used in ff is still bothering me, mostly the patch dir location
[01:04] <Ubulette> i also plan to drop timestamps from patches as it makes commits difficult to follow
[01:05] <Ubulette> easy with quilt
[01:05] <asac> Ubulette: what is bothering you with ff?
[01:06] <Ubulette> that I can't keep QUILT_PATCHES="debian/patches" in my ~/.quiltrc
[01:06] <asac> Ubulette: further, i never had timestamp problems ... do you refresh all the time?
[01:07] <Ubulette> no but you saw like me last week that if you touch one file in a big patch, all timestamps are updated
[01:07] <asac> Ubulette: why can't you keep that? because we have a link so you can just use quilt without QUILT_PATCHES set at all?
[01:08] <Ubulette> because ff does automaticaly 	  cd build-tree/mozilla && QUILT_PATCHES=patches quilt --quiltrc /dev/null pop -a -R || test $? = 2 ;
[01:08] <asac> Ubulette: well ... use: quilt --refresh --diffstat -U8 --no-timestamps :)
[01:09] <asac> Ubulette: oh ... i see ... QUILT_PATCHES=patches can be omitted ... its the default
[01:09] <asac> i have no .quiltrc
[01:09] <Ubulette> I do
[01:09] <Ubulette> QUILT_NO_DIFF_TIMESTAMPS=1
[01:09] <Ubulette> QUILT_PATCHES="debian/patches"
[01:09] <Ubulette> QUILT_DIFF_OPTS="-U8"
[01:09] <Ubulette> QUILT_REFRESH_ARGS="--diffstat -U8 --strip-trailing-whitespace"
[01:09] <Ubulette> it's far easier to work
[01:09] <asac> QUILT_REFRESH_ARGS="--diffstat -U8 --strip-trailing-whitespace --no-timestamps"
[01:09] <asac> QUILT_NO_DIFF_TIMESTAMPS is something differnt
[01:09] <Ubulette> no
[01:09] <asac> its for the diff command i guess
[01:09] <asac> no?
[01:09] <Ubulette> it covers both diff and refresh
[01:10] <Ubulette>  QUILT_NO_DIFF_TIMESTAMPS=1
[01:10] <asac> ah .. ok ... so you complain that i included them in the first place
[01:10] <Ubulette> i tested it on other projects
[01:10] <asac> ok fine ... we can drop them from all patches
[01:11] <Ubulette> nope. I just complain that because of QUILT_PATCHES=patches in ff, it's different from all other debian projects where you build with patches in debian/patches from the starting point
[01:12] <asac> ah ... ok ... its just because of the embeeded tarball thing
[01:12] <Ubulette> ?
[01:12] <asac> e.g. we work in a the build-tree/mozilla tree as if we would develop an upstream project with quilt
[01:12] <Ubulette> i missed my point
[01:12] <asac> while people that don't use embedded tarballs always work in a debian package