MOTU-2006-10-9
Differences between revisions 1 and 2
|
⇤ ← Revision 1 as of 2006-10-09 19:11:14
Size: 24126
Comment:
|
← Revision 2 as of 2008-08-06 16:25:11 ⇥
Size: 24126
Comment: converted to 1.6 markup
|
| No differences found! | |
04:01 dholbach OK everybody - welcome to the MOTU meeting 04:01 Gloubiboulga I can only stay ten minutes :/ 04:01 dholbach We try to keep this meeting short, as we all want to get back to fixing the last bugs in Edgy. :-) 04:01 dholbach Our agenda is quite short, it's over here: https://wiki.ubuntu.com/MOTU/Meetings 04:01 dholbach First point on the agenda is: "Prepare check lists for Universe/Multiverse for release." 04:02 dholbach In the previous release cycles we always had lists of things we wanted to get done === Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #ubuntu-meeting === minghua [n=minghua@danube.mems.rice.edu] has joined #ubuntu-meeting 04:02 dholbach like the python transition, the unmet dependency lists, ftbfs lists and other transitions 04:02 dholbach not to forget: Bug lists! 04:02 dholbach What do we have on the plate for Edgy release? 04:03 Fujitsu We ideally need to get a FTBFS list, 'cause an unmet deps. list is trivial... === StevenK [n=stevenk@14.5.233.220.exetel.com.au] has joined #ubuntu-meeting 04:03 dholbach Ok 04:03 dholbach 1) UnmetDeps list - easy to do, we can massfile bugs on that one 04:03 Fujitsu Yup. 04:04 dholbach 2) for the FTBFS list we can take the list of failed builds on launchpad 04:04 dholbach because I think that Adam (infinity) is too busy to do an archive rebuild at this stage. 04:04 Fujitsu dholbach, not really. A lot of things haven't been built in ages. 04:04 Fujitsu Yeah, true. 04:04 dholbach if anybody else has a feasible idea on that one, I'm all ears. :-) === sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #ubuntu-meeting 04:05 dholbach Do we have any open transitions we don't get by looking at the unmet deps list? === givr1 [n=Florent@APuteaux-152-1-17-31.w82-120.abo.wanadoo.fr] has joined #ubuntu-meeting 04:05 sivang dholbach: what about the python transition, is it all done ? 04:06 dholbach sivang: for Universe: I doubt it 04:06 sivang I see :-/ 04:06 dholbach sivang: doko_ fixed a lot and synced a lot from Debian, but I guess it's not complete (for Universe) 04:06 sivang yes, I see 04:06 dholbach Ok - anything else specific for the last days before release? === _MMA_ [n=mma@cpe-071-070-203-016.nc.res.rr.com] has joined #ubuntu-meeting 04:07 dholbach (If you can think of anything later on, just mail ubuntu-motu@) 04:08 siretart dholbach: we have that gnustep transition open 04:08 dholbach siretart: ah! how many packages does that involve? 04:08 siretart dholbach: you surely remember a series of UVF exceptions the last dats 04:08 dholbach siretart: yeah I do - are there other packages involved? 04:08 siretart dholbach: I'm not sure as I'm not familiar with gnustep at all 04:08 dholbach I see 04:09 dholbach I'll follow up with him. 04:09 siretart I remember a message from debian-release@lists.debian.org, that this transition isn't complete even in debian/etch 04:09 dholbach I'll write him after the meeting - let's hope we get that done for release 04:09 siretart ok 04:10 sistpoty what's that transition about... I remember quite a bunch of gnustep uploads at the beginning of edgy... 04:10 geser the gnustep transition will need several packages to be rebuilt or synced but I haven't checked in detail yet 04:10 geser I'm still trying to get all pieces built 04:10 minghua gnustep transition is almost finished in Debian from what I read from debian-release list 04:11 minghua some packages are still in NEW 04:11 geser gnustep-back needs to be built 04:11 sivang yes, also curious to know what the gnustep transition is about 04:11 sistpoty maybe s.o. could investigate and post to ubuntu-motu@l.u.c? 04:11 dholbach Ok, that sounds as if we're on a good way to get it fixed. 04:12 siretart yes, lets not block the meeting with that transitions. let's move on 04:12 dholbach For Universe/Multiverse Bugs: 1 75 of 2778 results is, what I currently see. 04:12 dholbach What is a good way to address those bugs? 04:12 dholbach ( http://tinyurl.com/p7moy ) 04:12 StevenK dholbach: Close the lot of them, of course. 04:12 dholbach ;-) 04:12 dholbach Right. 04:13 Fujitsu Write a script that iterates through and rejects them. Problem solved. 04:13 StevenK dholbach: Some of those 2778 probably apply to Hoary which can be found and slaughtered. 04:13 Fujitsu We have a bug-free universe. 04:13 dholbach I'm sure that a lot of old ones can indeed be rejected. 04:13 Fujitsu StevenK, probably. 04:13 dholbach that's rather a task for the opening of edgy+1 04:14 Fujitsu True... 04:14 dholbach in the process of uploading a fix for universe and multiverse in the last days we should always make sure to check the bugs in launchpad for that package 04:14 dholbach that way we can easily find bugs that can be closed with the upload and some even point to the debian bug with a patch 04:14 Fujitsu I've generally tried to do that for all of my uploads. 04:14 dholbach Fujitsu: Good work! 04:15 dholbach 1 75 of 157 results Uni/Multiverse bugs with patches 04:15 dholbach those are lowhanging fruit, I guess 04:15 siretart dholbach: I don't really see what we as motu team can decide or discuss about high bugnumbers, besides encouraging to participate in bug squashing sessions 04:15 dholbach I'll write a mail to ubuntu-motu@ about that later on 04:15 dholbach siretart: I only try to identify low-hanging fruit 04:16 dholbach things we can get fixed easily. 04:16 siretart dholbach: what we can do is to try to create reports about how many bugs we have open, how many are confirmed, important and have a patch, and list them in a report === StevenK makes a note to look at some of the bugs with patches when uni work has sent him insane. 04:16 dholbach siretart: nice idea - that would go well into a MOTU section on UWN 04:16 sistpoty from taking a glimpse on some bugs, some basic triaging (getting info etc.) might help... maybe we could do a hug day? 04:16 siretart in the hope that this encourages uploaders actually looking at bugs. debian has a weekly report about RC bugs 04:16 dholbach sistpoty: sure - sfllaw will be happy to see some people working on universe packages 04:17 dholbach Ok, I'll write a mail about Universe bugs. 04:17 sistpoty dholbach: great! 04:17 dholbach Who wants to massfile bugs on unmet deps? 04:18 dholbach I have a script for that - but if somebody else wants to do that, that's cool 04:18 Fujitsu I can do it, if others won't :) 04:18 dholbach Fujitsu: I think I'll also point to the failed builds on launchpad 04:18 dholbach Fujitsu: http://daniel.holba.ch/bzr/massfile 04:18 Fujitsu Thanks. 04:18 sistpoty would be good to have the packagename in the bug title (i guess that was a script bug last time *g*) ;) 04:18 dholbach hehe :-) 04:18 dholbach ok, let's move on - if some of you have clever ideas which bugs/fixes to address - follow up on the mailing list 04:19 siretart and tag them! :) 04:19 dholbach 2) Find agreement on StableReleaseUpdates for Universe/Multiverse 04:19 dholbach https://wiki.ubuntu.com/StableReleaseUpdates 04:19 Fujitsu Yes, that's particularly important to me, as I've got an update or two that need doing ;) 04:19 siretart dholbach: 1st question: do we have a -proposed upload target for universe? 04:19 dholbach Usually shortly after releases we get lots of requests for updates to <stable>-updated 04:19 dholbach -updates 04:20 dholbach siretart: I'm not quite sure, I'll investigate and let you all know. === dous [n=dous@ubuntu/member/dous] has joined #ubuntu-meeting 04:20 sistpoty just curious: did anyone do a SRU for uni/multiverse recently? 04:20 dholbach not recently 04:20 siretart dholbach: is someone only who we can ask? because I think this could be important for our further discussion of this point 04:21 siretart s/only/online/. gnarf 04:21 siretart sistpoty: I think LaserJock tried to do one, but mdz told him that we need a process for that first === lfittl is now here too, sry for being late 04:21 siretart sistpoty: thats why we are discussion that here 04:21 dholbach I asked in #ubuntu-devel 04:22 siretart thanks 04:22 sistpoty imo the entry barrier as proposed in SRU-updates is too high for universe... 04:22 dholbach that's my feeling too, sistpoty 04:22 Fujitsu siretart, I see an SRU for matplotlib by LaserJock. 04:22 sistpoty maybe we could get s.th. like motu-uvf in place for SRU policies and just get a final ack after the -proposed upload from ubuntu-archive? 04:22 siretart Fujitsu: oh. i see 04:22 dholbach <dholbach> What is the current state of -proposed? Does it work? Does it work for universe and multiverse as well? 04:22 sivang what's the SRU? 04:22 dholbach <Kamion> dholbach: working but restricted by policy (StableReleaseUpdates); yes; yes 04:22 dholbach sivang: STABLE RELEASE UPDATES 04:22 sivang dholbach: ah, right, sorry ! :-) 04:22 dholbach *cough* :) 04:23 sivang hehe === StevenK waits for his ears to stop ringing. 04:23 siretart I like sistpoty's idea (in fact, I wanted to propose something similar) 04:23 dholbach sistpoty: how do you think the testing process should work? === mindspin [n=mindspin@p54B24C3B.dip.t-dialin.net] has joined #ubuntu-meeting 04:23 dholbach ... testing part of the process ... 04:24 sistpoty dholbach: just some ideas so far...: 04:24 sistpoty only updates allowed with bug numbers === mindspin [n=mindspin@p54B24C3B.dip.t-dialin.net] has left #ubuntu-meeting ["Konversation] 04:24 sistpoty then we could "abuse" the ppl. filing the bugs to participate in testing 04:25 siretart (they are likely interested in actually testing fixed packages) 04:25 sistpoty the motu-uvf-alike team would also need to do some basic tests I guess 04:25 dholbach yeah that's the interesting part of the question: who do we ask to test? 04:25 dholbach bug reporters: good idea 04:26 siretart dholbach: the bug submitters and subscribed ppl to that lp bug 04:26 dholbach motu-uvf: bad idea - too much mails already ;-) 04:26 dholbach siretart: do you think that's enough? 04:26 siretart dholbach: let's call that group 'motu-sru' 04:26 sistpoty yay 04:26 sistpoty of course the uploader needs to test thoroughly *g* 04:27 siretart dholbach: I think yes. we cannot afford the same level of testing as in main 04:27 dholbach and that would be people who agree to do tests in the stable release now and then? 04:27 rmjb uvf? 04:27 dholbach rmjb: upstream version freeze 04:27 dholbach What about mailing them to UWN and announcing them - for people to test and have a look? 04:27 siretart dholbach: I don't understand, announce what exactly? 04:27 dholbach that would make sure we have a reasonably big tester community 04:28 dholbach "fixed packages of <...> available for testing." 04:28 siretart in form of a report section of UWN? sounds great! 04:28 dholbach yeah 04:28 minghua sounds a good idea, but I'm not sure how well that will work 04:28 Fujitsu Although some bugs already have large communities built up around them, so have a large testing ground already :P 04:28 sistpoty dholbach: sounds great... maybe we could increase the testing time a little bit (2-4 weaks?)? 04:28 Toadstool dholbach: and point the testers to the sru bug report, otherwise we'll get a whole load of dupes :) 04:29 sivang Yes, sounds like UWN would encourage people to do testing. 04:29 siretart minghua: we have to test. do you have another proposal? 04:29 dholbach because we need to get thorough testing done: be honest: all of us run the development release and seldomly test stuff in the last stable 04:29 minghua I have some input method related package I want to propose for SRU, but I doubt many testers are interested in testing them 04:29 sistpoty dholbach: so that proposed will become a kind of testing *g* 04:29 dholbach sistpoty: >= 2 weeks - yes, what I thought 04:29 sivang dholbach: well, setting up a dapper chroot is not hard :) 04:29 siretart dholbach: how does the -propsed queue work? do uploads get automatically built and published? 04:29 minghua siretart: not really, but I think the uploader/proposer should be more responsible 04:30 dholbach sivang: thoroughly using it, is 04:30 dholbach minghua: we have a cjk-testers team in launchpad - maybe you could subscribe them to that bug? 04:30 dholbach siretart: yes, in the <stable>-proposed section 04:30 sistpoty just a side though: we should try to limit new upstream versions though, maybe only for utterly broken packages or small diffs, since these would be a target for -backports imo 04:30 sivang so, that measn testers will have to have another box runnign dapper.. 04:31 minghua dholbach: a lot of bugs I want to fix have cjk-testers subscribed, not much activity from what I see 04:31 dholbach sistpoty: agreed 04:31 siretart dholbach: cool. I imagined that would be a moderated queue, similar to NEW or something 04:31 sivang sistpoty: indeed, make a lot of sense. 04:31 dholbach minghua: you could try to prod jono about making the team more active - maybe ask in the loco teams to get people involved there 04:31 Fujitsu sistpoty, of course. 04:31 minghua dholbach: sure, I'll think more about this 04:31 dholbach Wow, looks like we got some good ideas on that one. 04:32 siretart :) 04:32 minghua I'm just expressing my interest on SRU for universe here :-) === tomveens [n=tomveens@ztn-c-1566b.adsl.wanadoo.nl] has joined #ubuntu-meeting 04:32 sistpoty for testing, maybe we could make some silly "acks >= n" guidelines for packages, to see if updating in fact makes sense 04:32 dholbach Anyone wants to add something to it? 04:32 dholbach minghua: :-) 04:32 freeflying minghua: anything relate to zh_CN, ubuntu-cn would like test 04:32 minghua I think strict ack >= n is a good idea 04:33 dholbach might be a bit tough for obscure packages 04:33 sivang sistpoty: I'd say not >= , but they will have to provide X benefits on ground which we will update them. 04:33 dholbach but this is something we'll figure out along the way 04:33 minghua freeflying: not really, the things I have in my head is scim-chewing and scim-m17n 04:33 minghua freeflying: but thanks for the information 04:33 sivang so having something like "Does it fulfill A,B,C and E? okay let's update" 04:33 dholbach We need to flesh out this process perfectly, so it'll be easy for people to get involved in approving, forwarding, testing, etc 04:33 minghua freeflying: on the other hand, most zh_CN related scim stuff are in main anyway 04:33 sistpoty I wouldn't make it a strict policy (as dholbach just mentioned)... but rather a guideline which the sru-team could still override 04:33 freeflying minghua: but we wtill can test 04:33 dholbach yeah 04:34 rmjb testing on stable can be done in a virtual appliance? if users are running development? 04:34 dholbach Ok - let's put all of this into a wiki page later on and work on it together 04:34 sivang rmjb: for sure 04:34 minghua back to the ack >= n thing - if we can't get enough acks, it should mean not many users are interested in this package, shouldn't it? 04:34 siretart did we agree on a 'motu-sru' team? how many members and what quorum do we want to have? 04:35 sivang and when Xen is ready in edgy, it will even come out of the box IIRC. 04:35 dholbach I have the feeling that we won't solve the process entirely today. 04:35 sivang we need to start with somethign modest, 04:35 sivang and refine the process as we go 04:35 sistpoty minghua: it would... but some obscure packages that are utterly broken anyway would get of starved from this... so I'd make it just a guideline which can be overridden... 04:35 sivang *something 04:36 Fujitsu dholbach, of course, there is a lot to be decided. 04:36 dholbach Yes 04:36 sivang We can start with a very basic set of guidlines, and see what more we require by experience 04:36 rmjb the sru will also apply to dapper since that's LTS or does that already have something in place? 04:36 sistpoty minghua: also, testing by s.o. who's really knowing what he's doing is worth more then 5 tests of ppl. who don't have much clue ;) 04:36 minghua freeflying: you mean ubuntu-cn can still test packages in main, or test packages not about zh_CN? 04:36 dholbach I'll start on https://wiki.ubuntu.com/MOTU/Processes/SRU later on and will try to make the wiki page so everybody can add their proposal in easily 04:36 dholbach we should discuss the strict guidelines in another meeting === lukas_ [n=lukas@c-68-84-69-12.hsd1.nj.comcast.net] has joined #ubuntu-meeting 04:36 siretart or perhaps on the mailing list 04:37 dholbach good idea too 04:37 sistpoty +1 04:37 sivang +1 04:37 Fujitsu +1 04:37 dholbach so it gets some eyeballing before we finally agree in a meeting 04:37 freeflying minghua: we'd like test anything we can do :) 04:37 siretart next item? === bddebian [n=bdefrees@mail.ottens.com] has joined #ubuntu-meeting 04:37 minghua sistpoty: very true. if some one is willing to be responsible for the upload, then things can be overridden. :-) 04:38 dholbach MOTU Build Farm and Donation (HW, CPU time, and $) process (JordanMantha) 04:38 dholbach laserjock is not here 04:38 dholbach I think we probably should leave this one out for the next meeting - what do you guys think? 04:38 sistpoty yep 04:38 minghua is TheMuso here? 04:38 TheMuso TO be honest, I think its something that should be discussed on the ml. 04:38 siretart dholbach: perhaps you can give some details about this proposal? 04:38 minghua the proposal mail to -motu is his 04:38 TheMuso Its not something thats easily talked about on IRC> 04:38 bddebian I think some should just send me a PPC, Sparc, and amd64 and be done with it.. ;-P 04:39 siretart bddebian: I have a spare ultra1 ;) 04:39 dholbach siretart: I have no idea 04:39 dholbach siretart: it's his item :) 04:39 siretart ic 04:40 siretart hm. the original proposal was from Luke Yelavich 04:40 siretart dholbach: can we abuse edgy-proposed for that? 04:40 TheMuso A few of us were talking about it in -motu earlier today, and were throwing ideas around, but due ot the complexity of what might have to be done, I feel it it would be easier on the mailing list. 04:40 dholbach siretart: for what? 04:40 TheMuso IMO 04:40 Fujitsu I think this is fairly important, because I've run into a couple of bugs/FTBFSes in various things that only appear in PPC or [insert other obscure architecture here] . It's pretty much impossible to debug this sort of stuff without access to machines of the target architecture. 04:40 siretart dholbach: testuploading packages to see if they build on all architectures or for testing of patches? 04:40 Fujitsu And not all of us have non-x86 machines. 04:40 dholbach hmrmhrmhmrmhrmhrmhrmhrmhr 04:41 dholbach I don't like the idea much - the buildds are usually somewhat blocked already 04:41 TheMuso I wasn't thinking of using the build servers. 04:41 siretart dholbach: buildds can be prioritized. I imagine that very low priority 04:41 Fujitsu *cough* openoffice *cough* kde *cough* 04:41 dholbach not blocked, but you know that other stuff will be delayed 04:41 dholbach I don't like the idea much 04:42 TheMuso I am very well aware of their busy schedule. 04:42 dholbach you can ask on #ubuntu-devel - as it's not my decision 04:42 sistpoty imo it's not so much the problem to test if a package builds on all arches before a package is uploaded, but rather to get access to arch-xy if there is a build-failer on that arch 04:42 TheMuso Has everybody here read the original email I sent? 04:42 sistpoty failure even 04:43 minghua TheMuso: I read :-) === sivang looks for the email 04:43 minghua I think TheMuso's idea is not really a build farm, but something like Debian's developer's machine for all archs 04:44 minghua which MOTUs can log in and do test builds or debugging 04:44 minghua TheMuso: is that correct? 04:44 minghua and in that case we don't need the official buildds 04:44 minghua some machines in a MOTU's house works just fine 04:45 TheMuso minghua: SOmewhat. I was thinking of something where anybody who has hardware can donate its use for building/testing, but on a purely volintary basis. 04:45 Fujitsu Like what a couple of people do now. 04:45 TheMuso And have such systems in place so that if a user donates hardware, but has low bandwidth, their systems only build small packages. Same with CPU speed, and times of day. 04:45 TheMuso Fujitsu: Exactly. 04:46 TheMuso ajmitch raised some interesting points about security. I'd have to dig back through my -motu logs to find them however. 04:46 _MMA_ Hello all. LaserJock and I talked at some length about this. I have a AMD AM2 4600+ machine that I would like to compile packages on. Currently I cant package. I wanna learn but my current situations gives me limited time to learn new things. So we discussed I could process files without configuring everything. 04:47 _MMA_ I also wanted to donate some $ for hardware. 04:48 dholbach Can we start getting ideas together on a wiki page for that? 04:48 dholbach It looks like it's not something we can decide easily 04:48 TheMuso Thats a good idea. 04:48 sistpoty hm... just as a side idea: maybe we could also form amd64/sparc/ppc/whatever teams, that have access to that hw and to whom we could assign arch-specific bugs to. usually it's easy for s.o. who has that arch to fix the bug because he will know what's the problem 04:49 StevenK That's a big assumption. === hub [n=hub@toronto-hs-216-138-231-194.s-ip.magma.ca] has joined #ubuntu-meeting 04:49 sistpoty well.. usually as in for the easy fixes... of course there are tough tasks, which the team could reject then 04:49 StevenK I own an sparc64 and a parisc, doesn't mean I know anything about how the software functions in comparsion to an i386 04:49 TheMuso StevenK: Same with myself and my ppc. === phanatic_ [n=phanatic@dsl54009F59.pool.t-online.hu] has joined #ubuntu-meeting 04:50 rmjb sistpoty: with this proposal the person with the knowledge of the package can fix the bug since they'll have access to the different arches 04:50 dholbach we could add a subpage to the wiki about people and their hardware 04:50 sistpoty rmjb: sure... it was just an extra idea on top of that 04:50 dholbach and decide on a process to form those teams, etc 04:50 tomveens wiki idea: need a spokesperson for the page a one point to communicatie with about HW donation 04:51 dholbach http://wiki.ubuntu.com/MOTU/Machines ;-) 04:51 sistpoty the motu-machines :) 04:51 TheMuso heh 04:51 dholbach we can add all the security worries, process ideas, lists, mail addresses, everything to it 04:51 tomveens who's first? 04:52 dholbach I suggest we do that before we start to decide on something :) 04:52 dholbach but it was great to see some ideas thrown into the mix ;-) 04:52 TheMuso dholbach: Agreed. I just wanted to get it out in the open. 04:52 dholbach TheMuso: thanks a lot for that. 04:52 TheMuso np 04:52 dholbach next time and date? 04:52 dholbach I'd like to have it after the release === lbm [n=lbm@82.192.173.92] has joined #ubuntu-meeting 04:53 Fujitsu A couple of days after? 04:53 TheMuso Does anybody mind if I create the wiki page dholbach suggested above 04:53 dholbach Fujitsu: sounds good 04:53 Fujitsu Go ahead, dholbach. 04:53 tomveens okay === DBO [n=DBO@unaffiliated/dbo] has joined #ubuntu-meeting 04:53 TheMuso SO I can flesh out my original proposal a little more? 04:53 dholbach between release and UDS, after? 04:53 Fujitsu Oops, *TheMuso, not dholbach. 04:54 TheMuso :) 04:54 dholbach Ok, we can handle that on the mailing list as well. 04:54 dholbach Thanks a lot everybody for coming to the meeting! 04:55 TheMuso np 04:55 sistpoty thanks for the meeting ;) 04:55 dholbach Have a good time until the release - I know you're all going to ROCK! 04:55 Fujitsu THanks for running it :) === StevenK [n=stevenk@14.5.233.220.exetel.com.au] has left #ubuntu-meeting [] 04:55 dholbach de rien :)
MeetingLogs/MOTU-2006-10-9 (last edited 2008-08-06 16:25:11 by localhost)