20070301
Log
10:06 mdz cjwatson,Keybuk: let me know when everyone is accounted for 10:06 Keybuk mdz: everyone on my team is here 10:06 rtg cjwatson: pong 10:07 doko pong 10:07 cjwatson mdz: check 10:07 mdz ok, welcome all 10:07 mdz are all the summaries in as well? 10:08 Keybuk a few tardies, but yes 10:08 mdz I've added a bit to the calendar to remind us to send the reminder early 10:08 cjwatson all my summaries were on time 10:09 mdz any new agenda items? 10:09 asac i want to update my agenda item 10:09 asac its meant to be more general and not mozilla team specific 10:09 ogra a reminder reminder ? 10:09 heno I can just add a quick report from the LP meeting 10:09 asac update wiki or post updated version here? 10:09 mdz asac: go ahead and change the wiki 10:09 asac thx 10:09 mvo if we have time, maybe we can consider taking about https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-March/000414.html (but only if we have time) 10:09 mdz heno: oh, yes please. can we make that a regular item each week? 10:09 Keybuk mdz: I've moved my reminder up a bit 10:10 mdz mvo: sure, add to the wiki 10:10 cjwatson asac: your agenda item has an easy answer, but I left it there because I wanted to publicise that answer for more general use 10:10 heno I brought up the beta performance issues today, which they are now looking at 10:10 heno mdz: sure, good idea 10:10 heno I'll use email next time 10:10 mdz ok, let's dive in. 10:10 mdz (fabbione) Improving hw certification test coverage 10:10 fabbione yeps 10:10 asac cjwatson: it should be not that easy anymore :) 10:10 mdz fabbione: this was on the mailing list as well, no? 10:10 fabbione i did send a mail to distro-team 10:10 fabbione yes 10:10 fabbione but received only one reply so fat 10:10 fabbione far 10:11 mdz fabbione: the last time I talked about this with jbailey, my understanding was that there wasn't enough bandwidth in certification to perform more than basic tests 10:11 fabbione so this is an encouragment to at least let me know what's the status of your implementations 10:11 cjwatson asac: with regard to your previous item, the answer as I understood it was http://wiki.ubuntu.com/DebuggingProcedures 10:11 mdz this was when I was asking for help with different installer test cases, e.g. 10:11 pitti still, even if these cannot be implemented right now, I think it makes sense to keep them in the specs for later manual verification 10:11 fabbione mdz: probably not for feisty, but we can start as much as we can 10:11 cjwatson which is something I'd like to encourage people to add to in general 10:12 mdz cjwatson: hmm, is DebuggingProcedures not on UbuntuDevelopment yet? 10:12 fabbione mdz: also because automation requires implementation and having an overview ASAP it's better 10:12 asac cjwatson: ah ok 10:12 pitti it also makes reviewing old specs much easier in later releases 10:12 fabbione that will let certification team more time to develop their test cases 10:12 cjwatson asac: though I guess workflow is slightly different from debugging procedures 10:12 heno I'll be looking at restructuring those pages btw 10:12 mdz fabbione: I think it's a fine idea for them to participate in feature testing, but I wouldn't want us to spend time defining tests if they won't be carried out 10:12 cjwatson er bug handling procedures 10:12 heno with a more uniform naming structure 10:12 asac cjwatson: lets talk about that if its on topic :) right? 10:12 fabbione mdz: the tests need to be hw specific. it's clear we are not going to ask them to test everything 10:12 cjwatson asac: sure 10:12 heno (more on the -devel list) 10:13 asac ;) 10:13 cjwatson mdz: not yet, I'll add it 10:13 fabbione mdz: but only what involves/might involve hw specific 10:13 fabbione -ETOOMANYCONVERSATIONS 10:13 mdz is there anything other than compiz which is high-profile and hardware-specific? 10:13 mdz we would certainly like for them to test that 10:13 kylem fabbione, one of the things i'd like is add the linux firmware kit to the list of tests we do for certification. 10:13 fabbione kylem: noted. 10:13 kylem fabbione, so we can know what's a kernel bug, and what is a BIOS bug, for things like PCI MMCONFIG, etc. 10:13 pitti fabbione: oh, I misunderstood it as you also wanted non-hw-specific tests, i. e. verifying general features that specs implement 10:13 kylem fabbione, thanks. 10:14 fabbione mdz: ok. 10:14 Mithrandir mdz: accelerated-x, network-roaming, binary-driver-education, driver-backports at least, just to pick a few of the top ones. 10:14 fabbione pitti: eheh you are too good dude :) 10:14 doko mdz: EMT64 10:14 fabbione ok but we shouldn't spent too much time here in the meeting... please developers review your spec if they can affect hw (or viceversa) and let me know asap 10:14 pitti fabbione: well, as I said, having these tests written down in the specs is a good thing regardless of the guys implementing them right now :) 10:14 fabbione pitti: fully agreed 10:15 mdz Mithrandir: accelerated-x is compiz, network-roaming is a good one to test, as is binary-driver-education (though very coarsely) 10:15 Mithrandir pitti: but that shouldn't be done in the last month and a half of a cycle, so while we should discuss it now, doing anything much for feisty is just not feasible. 10:15 bdmurray kylem: where should linuxfirmware kit reports like 79226 go? 10:15 mdz fabbione: how about for feisty+1, you review the list of targets and check for ones which could affect certification? you can check with the people working on it if you have doubts 10:15 pitti Mithrandir: well, it does make sense to write down the tests when the spec is actually implemented 10:15 fabbione Mithrandir: we might still be able to test some stuff... 10:16 kylem bdmurray, woah. wtf. 10:16 fabbione mdz: for feisty+1 i want a settled entry in the specs.. 10:16 kylem bdmurray, reject it... why would that be in launchpad? 10:16 fabbione mdz: but yes.. 10:16 fabbione i still think it's important we try to test feisty too 10:16 fabbione if we can good.. if we can't... well same as now 10:16 mdz ok 10:17 mdz fabbione: is that sufficient for this meeting? 10:17 fabbione mdz: yes. i just would like people to send me the info i asked asap if they are not too overloaded 10:17 fabbione otherwise i am all good 10:18 mdz fabbione: probably the best would be to confirm with each developer whether they've reviewed, then you know when everyone has input 10:19 mdz otherwise you don't know whether you've received all broadcast responses 10:19 mdz but right, moving on 10:19 fabbione mdz: ok 10:19 mdz (pitti) [WWW] https://launchpad.net/bugs/67925 (which translations/input support do we want to ship on CDs): it basically boils down to 'ship Chinese with complete input support vs. don't ship Chinese at all, and two dozen of other translations'. Does anyone know a good and objective data source about Ubuntu popularity that can help us decide? 10:19 Ubugtu Malone bug 67925 in Ubuntu "Do not ship translations without matching input support" [High,In progress] 10:19 mdz pitti: I put this question to Canonical bus. dev. in January 10:19 mdz however, I didn't take into account the tradeoffs available between translations and input support 10:19 pitti ah, good idea, they probably know better about popularity 10:20 mdz pitti: could you send me a table of the cost (size) for each language? 10:20 pitti mdz: the bug has the options with rough numbers 10:20 mdz pitti: beta is slow for me 10:21 pitti for everyone :( 10:21 mdz pitti: does it also have the amount of space available to spend? 10:21 mdz (approximate) 10:21 pitti I hope this is due to beta running on a slower server and not due to general code slowness 10:21 mdz ok, it's loaded 10:21 pitti mdz: no, since this drastically changed just today 10:21 heno it's general code slowness :( 10:21 mdz the bug doesn't seem to have the information I'd want 10:21 heno but they are working on it 10:21 mdz if we're to balance the tradeoffs, I'd like to see size for each available language 10:21 pitti mdz: ok, I'll add a comprehensive table to the bug 10:22 Mithrandir mdz: space available to spend on the CDs? Zero, usually. We have to take something out to fit something else. 10:22 mdz pitti: for languages requiring input support, it should include that 10:22 pitti mdz: best is probably if I modify my langpacksize script to take into account input support as well 10:22 mdz Mithrandir: we ship a certain quantity of l10n data already 10:22 mdz pitti: yes, then we can have just one number per language 10:22 mdz pitti: and can choose the top N for the space 10:22 pitti ACTION: pitti to update langpack size script to include input support packages 10:22 pitti mdz: but that wasn't really my question 10:23 mdz ACTION: pitti to send output to mdz, mdz to pass to bizdev for ranking 10:23 Mithrandir pitti: please tell me when you have that ready, since I want the input for release thingies. 10:23 pitti Mithrandir: yep, will do 10:23 mdz pitti: that will be implicit in the data; we'll get their input based on shipit, commercial activities, etc. and set priorities 10:23 pitti ok 10:23 mdz pitti: don't worry, I'll answer the real question :-) 10:23 pitti mdz: that works for me, thank you 10:24 mdz asac) do we allow teams to maintain their individual tag/state/bug policies for a subset of packages? If we do so (hopefully yes), how can we properly document and communicate this so arbitrary QA/bug team members still can contribute to bug triage for those packages. 10:24 mdz cjwatson: you wanted to field this? 10:24 asac yes ... 10:24 asac my idea is a QA/Bug team page that lists teams (and what packages are associated with that team) that maintain a special bug policy 10:25 cjwatson well, the brief answer as above was DebuggingProcedures, but initially I thought asac was talking about general triage procedures rather than specifics of team bug handling 10:25 mdz I believe there exists such a resource in the BugSquad documentation, including DebuggingProcedures 10:25 asac + in the long run in launchpad: provide a link to team policy if package of current bug is maintained by a team that has a refined tag/state/bug policy 10:25 cjwatson however, I think it does fit in reasonably well in DebuggingProcedures 10:25 mdz bdmurray: do you know if that's in good shape? 10:25 cjwatson I know that DebuggingUbiquity has comments on bug policy 10:25 cjwatson mdz: this is something we talked about in the QA call yesterday 10:25 dholbach we already have: https://wiki.ubuntu.com/BugSquad/Tags and I started https://wiki.ubuntu.com/Bugs/Teams quite some time ago 10:25 bdmurray mdz: DebuggingProcedures is being worked on 10:26 cjwatson I would like to encourage everyone with non-trivial-to-debug packages to write short documentation on them and link it from DebuggingProcedures (as DebuggingPackageName) 10:26 asac anyway ... i doubt if everybody really looks at those pages regularly ... thats why i would like something in launchpad 10:26 asac at least a disclaimer 10:26 cjwatson asac: bug triagers do, AIUI 10:26 mdz asac: we've asked for a per-package text field which would be displayed on the bug page 10:26 pitti cjwatson: can we bless this as an ACTION item? 10:26 cjwatson pitti: I don't want to have actions for the whole team, really 10:27 cjwatson too hard to decide whether they're finished 10:27 asac mdz: .... maybe somehow allow per-package ... as well as per-team info would help a lot 10:27 mdz the push for this should come from QA 10:27 cjwatson it's an ongoing thing I'd like to encourage, that's all 10:27 pitti right, just as a reminder 10:27 mdz if there are questions about how to handle bugs for a specific package, documentation should be provided by a developer 10:27 cjwatson mdz: yes 10:27 mdz but it needs to be asked for, so that we focus on the most important bits 10:27 cjwatson I've asked Brian to establish a list of the most important items 10:27 cjwatson which can then be filled out over time 10:28 mdz sounds good 10:28 mdz asac: are your questions answered? 10:28 asac hmmm .... so how do triagers get that info 10:28 asac ? 10:28 cjwatson new triagers are pointed to the documentation, and AIUI encouraged to re-read from time to time 10:28 mdz asac: part of the process of joining the QA team is learning the documentation 10:29 asac ah ... ok ... lets see how well it works when i added that info 10:29 mdz asac: bdmurray can provide details of the process 10:29 cjwatson yes, it would be nice to have Launchpad prompt people; that's not something we can resolve immediately, but it's on their list 10:29 bdmurray asac: I would e-mail the bugsquad team too when that info is added 10:29 mdz asac: in order for existing QA members to become aware of it, it would be wise to inform them of new documentation 10:29 bdmurray so they know there is new information 10:29 asac yep ... all clear for now :) 10:29 cjwatson bdmurray: is the address on the wiki pages themselves? 10:29 mdz asac: in general, bdmurray is your point of contact for communicating with them 10:29 cjwatson bdmurray: (it should be) 10:30 bdmurray cjwatson: "the address"? 10:30 mdz cjwatson: we could use a section about the bugsquad/qa team on UbuntuDevelopment, especially how to interface with them 10:30 mdz bdmurray: the contact email address for the team 10:30 bdmurray got it 10:31 cjwatson along with instructions 10:31 mdz cjwatson: could you/bdmurray arrange that between you? 10:31 cjwatson ACTION: cjwatson/bdmurray to add instructions on interfacing with bugsquad/qa to UbuntuDevelopment 10:31 mdz what the bug squad is and how/when developers interact with it 10:31 mdz thanks 10:31 mdz moving on 10:31 mdz (Riddell) I plan to upload patches to dist-upgrade tool unless anyone objects 10:31 mdz Riddell: meaning the upgrader tarball? 10:32 Riddell the patches to edgy-proposed 10:32 Riddell the upgrader tar is stuck in soyuz somewhere 10:32 mvo Riddell: it should be fixed now 10:32 mvo Riddell: the latest is available 10:32 mdz Riddell: the patches to several packages to support kubuntu release upgrades? 10:33 Riddell mdz: yes, they're been greatly reduced since I first proposed them and pitti seems happy with the last review he gave 10:33 mdz Riddell: if it has SRU approval, then I'm OK with it 10:33 pitti oh, I still need to review your latest corrections, I think 10:33 cjwatson the upgrader tar was rejected because the _all was built in binary-arch; mvo has fixed that 10:33 pitti Riddell: tomorrow is my next archive/SRU review day, I'll come to that then === mvo coughs 10:33 Riddell pitti: great 10:33 cjwatson (binary reject reasons are hard to dig out of Soyuz) 10:34 mdz Riddell: all done? 10:34 Riddell yes, thanks 10:34 mdz (bdmurray) [WWW] https://launchpad.net/bugs/63175 - fsck not updating date checked possibly related to Feisty ([WWW] https://launchpad.net/bugs/78801) fsck issue 10:34 Ubugtu Malone bug 63175 in e2fsprogs "Edgy Beta -- fsck on every (re)boot" [Medium,Confirmed] 10:34 mdz iirc we stopped setting the time-based flag in the superblock some time ago 10:34 bdmurray This is something I have also seen bug reports about in Feisty. 10:34 mdz [...everyone waits for beta to load...] === kylem blinks. 10:35 mdz perhaps fsck behaviour has changed 10:36 mdz hmm, wait, that's definitely not right 10:36 mdz there should be no ...has gone N days without... 10:36 mdz cjwatson: didn't we disable that in the installer? 10:36 mdz (because of clock skew madness issues) 10:36 cjwatson only for dos due to specific brokenness in dosfsck 10:36 cjwatson er fat 10:36 cjwatson I think it's a really bad idea to turn off fsck across the board 10:37 cjwatson I can't imagine I'd have done that 10:37 mdz or was it the mount count check? 10:37 mdz the mount count check is not really appropriate for desktop/laptop systems 10:37 cjwatson TTBOMK the installer hasn't changed 10:37 heno it still does mount count check, my box did that yesterday 10:37 mdz I'm not entirely sure about forcing a check of a marked-clean filesystem without user request on desktops 10:37 cjwatson tune2fs(8) has a rant about why you shouldn't turn off mount count checking 10:38 cjwatson even if the fs is marked clean 10:38 mdz the user experience when fsck runs is pretty poor 10:38 cjwatson we should fix that, but not by disabling it 10:38 ogra how about setting it to 90 instead of 30 10:38 cjwatson there's a spec for it too 10:38 kylem cjwatson, that isn't horribly valid now that we have CRC checks on DMA to ide disks and such... 10:38 mdz yeah, we've talked about it for a while 10:38 heno mine was some odd number yesterday like 22 10:38 Mithrandir fsck+usplash you mean? 10:38 Seveas [if beta remains slow: just disable redirection on the old launchpad.net frontpage :)] 10:38 cjwatson Mithrandir: yes 10:39 Mithrandir that's feisty+1 material, though. 10:39 cjwatson kylem: I think "kernel bugs" still applies ;-) 10:39 cjwatson (given that ext3 oopsed several times on me not that long ago ...) 10:39 kylem cjwatson, nah. :) 10:39 kylem it's perfect, it just doesn't like you. ;-) 10:39 pitti heno: IIRC they are all 'almost prime' to make it less likely to get fscks on multiple partitions at the same time 10:40 heno ok 10:40 pitti heno: (in fact the ones I saw were pimes; 23, 29, 31, and such) 10:40 mvo we could implement someting so that the user can skip/stop the check at least 10:40 cjwatson anyway, does somebody want to volunteer to sort that bug out? 10:40 pkl_ kylem: that's not what Andrew Morton called it at Fosdem :-) 10:41 Seveas pkl_, :) 10:41 cjwatson I don't think attempting to either (a) debug it on the fly in the meeting or (b) redesign the entire system in the meeting is a good idea 10:41 mdz cjwatson: agreed 10:41 kylem cjwatson, i don't know... i did a feisty daily install on monday with nothing wrong with fsck... but, yeah, another place. 10:41 cjwatson can anyone on the team reproduce this problem? 10:41 mdz cjwatson: why don't you and bdmurray follow up after the meeting and allocate someone to help 10:41 cjwatson or rather, has anyone reproduced it? 10:42 cjwatson sure 10:42 bdmurray cjwatson: I thought you mentioned it happened to ogra after installing Feisty. 10:42 mdz I've never seen it; it sounds like it probably happens when the clock is borked 10:42 cjwatson ogra's education rather than distro thoughe 10:42 cjwatson -e 10:42 ogra :P 10:42 ogra i havent seen it today during testing 10:42 cjwatson ogra: no disparagement intended, but your priorities lie in different places and we don't manage you :-) 10:42 ogra it happened on all herds to me 10:42 mdz I expect that setting the hardware clock to zero would reproduce it 10:42 kylem might be worth asking marc, he does a lot of installs. :) 10:43 pitti I did lots of test installs recently and never saw it 10:43 cjwatson ACTION: cjwatson/bdmurray to find somebody to fix 63175 10:43 mdz ok 10:43 cjwatson let's move on 10:43 mdz (mvo) use of XS-Vcs-* in debian/control [WWW] https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-March/000414.html 10:43 ogra i'm happy to help though 10:43 cjwatson mvo: a fine idea 10:44 mvo XS-Vcs-bzr is about making the transition to bzr maintained packages easier. A lot are maintained in bzr already and the number is growing, but a lot are not. 10:44 mvo I would like to proposed that if you see (e.g. during a transition) a XS-Vcs-bzr field, commit directly or notify the maintainer. If you maintain your packages in bzr, add this tag to debian/control so that people touching the package know to send notification or commit into the bzr tree 10:44 mdz mvo: this belongs on ubuntu-devel as it's directly relevant to development and needs feedback from people actively developing 10:44 mvo mdz: yeah, my bad. shall I just re-send there? 10:44 Mithrandir mvo: how would that field look when the source is in the package? 10:44 pitti mvo: that needs some tool support, though 10:44 mdz mvo: please do, yes. I'll replay my comments there 10:44 cjwatson Mithrandir: it should be pushed to bazaar.launchpad.net anyway for the packages we maintain 10:45 pitti mvo: apt-get source at least warning you or so 10:45 mdz in order for this to work well, I expect we need to find some way to detect the case where a bzr-maintained package is being uploaded without updating bzr 10:45 mvo pitti: we could add this 10:45 cjwatson if you have an example of one maintained by somebody else that isn't pushed anywhere else, feel free to bring it up, but otherwise that seems academic 10:45 mdz and error out (overridably) 10:45 Mithrandir I have played with the idea of making the casper build fail if you have uncommitted changes. 10:45 Mithrandir (with an override mechanism, yes. :-) 10:45 mdz we could require that the build be done from bzr, but that may not be appropriate in all cases 10:45 cjwatson (speaking of which, the debian-maintainer-field error needs to be overridable) 10:46 Keybuk cjwatson: thinking of a particular example? 10:46 LaserJock people just building packages at home 10:46 cjwatson Keybuk: we've had a number of complaints from people building local versions of *ubuntu* packages that haven't had their source changed yet 10:46 seb128_ yeah, it's pretty annoying to rebuild debug packages 10:46 cjwatson it's obviously a bug that it doesn't use dpkg-source's normal errors-can-downgrade-to-warnings mechanism 10:47 cjwatson anyway, sorry, this is just a bug rant, not meeting fodder 10:47 Keybuk *nods* 10:47 mdz tricky problem to get the check right often enough 10:47 Keybuk the recent dch handling where you couldn't *not* get "ubuntuN" on the end annoyed me 10:47 mdz if only debian required debian.org maintainer addresses... 10:47 doko and its common to have "<releasename>" instead of "ubuntu" in the version 10:47 mdz doko: false negatives are a minor issue, false positives are bad 10:47 mdz which is sort of an argument for it being a warning instead of an error 10:48 mdz except that builds are so noisy that nobody sees warnings 10:48 doko add banner to build-essential 10:48 cjwatson even without tool support, XS-VCS-Bzr would be a win for people who practice some degree of diligence, since it would save them time having to go to BzrMaintainedPackages all the time 10:48 mdz perhaps we should downgrade to a warning for release, to avoid interfering with local builds 10:48 cjwatson doko: hah 10:48 mdz cjwatson: and it would increase the chances of that page being kept up-to-date 10:49 cjwatson make it controlled by an environment variable that all the distro team set but nobody else has to 10:49 mdz or rather, replacing it with something autogenerated which would be more likely up-to-date 10:49 cjwatson UBUNTU_I_AM_A_DEVELOPER=1 10:49 mdz grep ubuntu $DEBEMAIL 10:49 Keybuk DEBMAIL~=ubuntu.com ? 10:49 pitti $DEBEMAIL ~= ubuntu 10:49 cjwatson yes! 10:49 pitti Keybuk: heh, snap 10:49 cjwatson then it can fail hard 10:50 mdz pitti: will you take the action for that? 10:50 pitti mdz: fine for me 10:50 mdz ACTION: pitti to fix up dpkg-dev to only error hard if $DEBEMAIL contains ubuntu 10:50 mdz (Riddell) do we want hwdb ask-email ? 10:51 pitti mdz: (what a nasty hack...) 10:51 Riddell I thought lifeless had implemented this in the gnome hwdb client ages ago 10:51 mdz Riddell: if the question is whether we want hwdb-client to ask for an optional email address, yes, absolutely 10:51 mdz pitti: nasty hacks R us 10:51 Riddell but I looked today and he hadn't 10:51 mdz Riddell: I remember talking to lifeless about it 10:51 mdz and I thought it was done too 10:51 Riddell mdz: there was a branch, but no commits 10:51 mdz Riddell: maybe chase lifeless and see if he has code elsewhere? 10:51 Riddell mdz: I did, he doesn't 10:51 mdz oh 10:51 Riddell I'm happy to do it in both frontends if we don't mind breaching feature freeze 10:52 mdz Riddell: if the release team is happy, I'm happy. it's very much worth having 10:52 Riddell I'll code it up and ask the release team to review 10:53 Mithrandir as long as it's small enough, I'm fine with it. 10:53 mdz great 10:53 Mithrandir note that we're actually quite close to release now. Release is in a month and a half, betafreeze is in two weeks. 10:53 mdz Mithrandir: speaking of freezes and such, how are we doing? 10:54 doko Mithrandir: do we have results from the rebuild tests? 10:54 Mithrandir mdz: the targetted bug list is at ~100 bugs right now, which is too much. I'll go through it and see what low hanging fruit there's to catch there as well as prod people to concentrate on the important bugs. 10:54 Riddell ACTION: jonathan to implement ask-email in hwdb-client 10:54 Mithrandir doko: I haven't received those yet, no. I'll follow up on that. 10:54 Mithrandir ACTION: tfheen to get rebuild test results and publish them somewhere. 10:54 mdz Mithrandir: I feel like we should have a policy about targeted bugs and assignment 10:55 mdz there should be a path by which bugs which are clearly real targets should be assigned as a matter of course 10:55 mdz Mithrandir: do you review that from time to time? 10:55 Mithrandir mdz: so far I've encouraged people to add a milestone if they believe a bug is important; the team is my ears and eyes. 10:55 Mithrandir yes, I try to go through the list of bugs and downgrade the ones I don't think are really RC. 10:55 mdz Mithrandir: but it happens occasionally that a bug is targeted without having an assignee yet 10:55 ogra Riddell, ?? 10:56 Mithrandir mdz: yes, I'll get that fixed when I go through the list next time. 10:56 mdz in which case there's no one for you to nag 10:56 Riddell ogra: see discussion 21:50 10:56 Mithrandir I'll find somebody. :-) 10:56 Mithrandir I've also gone through the list of specs and will talk with the responsible people to see what needs to be deferred and what can be rescued. 10:56 mdz there should be plenty of bandwidth for RC bugs now that we're in feature freeze 10:57 mdz that's our focus 10:57 ogra Riddell, i dont think it was ever implemente3d and lifeless refused to touch the GUI 10:57 Riddell ogra: quite a hard feature to implement without touching the GUI :) 10:57 mdz ok 10:57 mdz any other business for the meeting? 10:57 ogra Riddell, exactly :) 10:57 heno I'll just post the LP stuff: 10:58 heno == Launchpad meeting report == 10:58 heno * I raised the performance issues in beta. They will do some profiling and esp. look at how the JS and CSS files are loaded, perhaps inlining some of it 10:58 heno * That also raised the general point of how to file or tag bugs that are beta-specific (like performance or the failure to fit in a small window). The suggestion of a 'beta' tag was rejected. It was suggested we use the tag '1.0' (which means fix this before 1.0 is out, so not quite the same IMO) 10:58 pitti mdz: a small announcement 10:59 Mithrandir heno: is there any data we can provide which helps the developers fix the performance bugs? 10:59 heno Mithrandir: yes, I think you did some comparative timings AFAIR 10:59 heno that should be useful 10:59 heno or use Firebug I think it's called 11:00 Mithrandir yes, I used firebug and looked at the load times. 11:00 cjwatson heno: 1.0 seems like a reasonable default for regressions in the beta from current production 11:00 heno which analyses traffic on page loads 11:00 heno cjwatson: that's true 11:00 heno these are basically regressions 11:01 heno though they may also be beta-specific nits 11:01 heno not worthy of 'fix-before-1.0' status 11:01 heno anyway ... 11:01 mdz ok 11:01 cjwatson it's not clear to me when something is strictly beta-specific (i.e. something that will only be true of the beta and somehow not true when it is deployed on launchpad.net) 11:01 mdz we're out of time === pitti raises hand 11:02 mdz pitti: please go ahead 11:02 pitti I have a little surprise, especially for crashmaster seb128 and segvmaster dholbach: just three minutes before the meeting I got the apport fakechroot stuff working 11:02 pitti i. e. I can now build and use chroots for apport-retracing entirely with user privileges 11:02 pitti right now you still have to call it manually, but that at least solves the 'I do not have this architecture' problem, as well as bandwidth issues 11:02 dholbach pitti: YOU ROCK :) 11:02 seb128_ rock on ;) === seb128_ hugs pitti 11:02 mdz pitti: neat! === dholbach hugs pitti 11:02 pitti it should be relatively easy to search for bugs with unretraced crashes and add comments with debug stack traces automatically; I'll do that in my 'after hours' in the next time === dholbach hugs seb128 too 11:02 pitti to roll this out to the porter machines in the DC, I just need RT#26845 fixes (installation of fake[ch] root on porter machines); maybe I can get a little pushing from the management folks to get this sorted out soon? :) 11:02 ogra pitti, you made fakechroot work ???? !!!! === ogra hugs pitti === seb128 hugs dholbach back 11:02 mdz pitti: if you write a document explaining how to do it, that can be farmed out to the QA team 11:03 pitti mdz: right, but my idea is to make it fully automatic 11:03 iwj__ pitti: I should look at that, as I think I might want to attach some of my autopkgtest tendrils if you have a fakeroot-based chroot builder. 11:03 pitti file a crash bug, half an hour later you have the retrace 11:03 mdz pitti: sure, that'd obviously be better 11:03 iwj__ (Well done, btw.) 11:03 pitti iwj__: sure, I have it in a Python class 11:03 iwj__ Right. I'll ask you about it tomorrow. 11:03 pitti mdz: the only problem is that fakeroot needs to be apt-get isntall'ed, because of this /usr/lib/libfakeroot.so stub 11:03 pitti that's why I need that RT 11:04 mdz pitti: I'm sure we can get that installed on a server in the DC 11:04 ogra pitti, does that mean i can use fakechroot in a normal way for ubuntu systems as well ? 11:04 pitti ogra: well, why not? 11:04 pitti ogra: the package itself is ages old 11:04 pitti of course it's pretty limited, but it's just perfect for apport-retrace's sake 11:04 ogra i know but i didnt manage to get an ubuntu chroot working in edgy 11:05 pitti anyway, technical stuff, not for the meeting 11:05 mdz right, truly out of time now 11:05 mdz thanks, everyone 11:05 mdz good night
MeetingLogs/UbuntuDev/20070301 (last edited 2008-08-06 16:19:49 by localhost)