16:00:07 #startmeeting Fedora QA Meeting 16:00:07 Meeting started Mon Aug 31 16:00:07 2009 UTC. The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:07 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:15 #topic gathering in lobby 16:00:44 * kparal is present 16:00:50 Hey folks ... let's do a quick show of hands 16:01:17 dpravec is just making coffee/tea, otherwise present 16:01:23 * nirik is hanging out in the back. 16:01:46 mornin 16:01:52 * fenris02 is waiting for the tea to be finished 16:01:54 kparal: nirik and dpravec_caffeine ... hello 16:02:08 adamw: fenris02: good mornin' 16:02:14 * psss is here, hi! 16:03:04 psss: hey there 16:03:10 jlaska: psss will be here only 30 minutes 16:03:27 dpravec: okay ... we've got autoqa lined up early in the agenda 16:03:28 * Oxf13 16:03:35 Oxf13: hey hey 16:03:56 is there a wwoods lurking in the shadows? 16:04:10 * wwoods is batman 16:04:15 LOL! 16:04:29 alrighty ... let's doo eeeet 16:04:47 #topic previous meeting follow-up 16:05:11 dpravec: I've got you up first ... how goes it with test-announce? 16:05:15 # [dpravec] - investigate creating fedora-test-announce mailing list for Test Days, other test events, schedule updates 16:05:55 ah, i almost forgot. but mailing list test-announce is ready to be used 16:06:22 yay 16:06:29 who's set as a moderator? 16:06:29 its moderated list with low traffic - so people will get info about testing without getting much spam 16:06:41 adamw: if i am not mistaken, you are 16:06:52 alright, I'll ask sdziallas to be our test candidate this week for sugar on a stick announcement 16:07:22 I forget, mailman uses a single admin passwd? 16:07:23 is fedora-test-list subscribed to the announce list, as suggested last week? 16:07:54 adamw: hmm not yet, but i will try to fix this today/tomorrow 16:08:18 hmm i dont know how :) 16:08:42 ha, just subscribe it ;) heh 16:08:50 ok, will do 16:08:57 yes, you can just subscribe it from the admin pages 16:09:12 dpravec: can you add me as a moderator as well? 16:09:20 * tk009 arrives late 16:09:20 yes, i already did 16:09:31 hi iarlyy, tk009 16:09:32 dpravec: thanks ... I think that gets us decent TZ coverage 16:09:34 * iarlyy arrives late tool x) 16:09:42 s/too 16:09:52 howdy iarlyy and tk009 :) 16:10:18 =) J & A 16:10:27 & I 16:10:28 hey adamw jlaska 16:10:31 alrighty, I've got a few action items .. wil walk through quick ... 16:10:38 # [jlaska] - talk with Liam about how we can make the current install test plan more attainable/achievable in the given time frames 16:10:55 I didn't have a chance to catch up with Liam on this last week ... but will follow-up on this probably tonight 16:11:19 so I'll keep this on for next week ... and see if maybe Liam has any points he wants to address for the minutes as well 16:11:24 next ... 16:11:49 * jlaska just speeding through ... so shout for a stop 16:11:53 # [jlaska] - cleanup remaining test cases for dracut and send announcement 16:11:56 so, iam adding fedora-test-list@redhat.com to members, ok? 16:12:19 #action dpravec will subscribe fedora-test-list to test-announce 16:12:25 dpravec: I think that's how it works 16:12:51 #action jlaska - catch up with lili on some test plan changes for the upcoming F-12-Beta milestones 16:13:08 .. done 16:13:35 dracut test cases were in good shape ... with help from atodorov and jstodola 16:13:45 there is one missing still for root=udev-path ... but I need to test that first 16:14:09 next item ... 16:14:11 # [jlaska] - discuss bandwith implications of hosting nightly rawhide live images with fedora-infrastructure 16:14:21 https://admin.fedoraproject.org/mailman/listinfo/test-announce <-- maillist page 16:14:31 dpravec: thanks! 16:15:09 Oxf13, nirik: I spoke to mmcgrath on the fedora-admin briefly a little bit ago on the alt.fp.org bandwith 16:15:33 ok 16:15:49 we had problems with live images for f11 16:15:50 ? 16:16:09 the summary is that there haven't been any issues reported yet, and he'd like to be kept in the loop when new milestone drops land 16:16:20 no nightly rawhide iarlyy 16:16:26 * nirik is happy to adjust/change/whatever the live composes. Just let me know. 16:16:32 did he have any numbers on how many downloads we've been getting on the nightly builds so far? 16:16:34 iarlyy: yeah, this is for hosting live images 16:16:48 adamw: I didn't ask, but I Think those would be reasonable to gather ... I can follow-up 16:17:03 I've been using them and been happy 16:17:09 I note that rawhide has been busted with broken deps for a bit now, so there have been no new images recently. 16:17:12 mmcgrath did note that they're interested in building a mirror to host content should any issues surface on that one system 16:17:18 nirik: yeah :( 16:17:20 i have discussed with nirik the possibility for using zsync tool (http://zsync.moria.org.uk/) for downloading images. it is similar to rsync, but works on plain http. it saves time and bandwidth for users and servers. unfortunatelly zsync is not packaged yet for fedora, so the conclusion is it is not relevant yet 16:17:32 * mmcgrath actually just kickstarted said machine. It'll be ready by the next time you guys do this. 16:17:38 go mmcgrath! 16:17:48 nirik: yeah, stuck in the middle of an openssl rebuild i think. 16:17:54 kparal: for live images, rsync is actually the wrong thing to use 16:18:04 kparal: we can't use it until it is. ;) There is also deltaiso's... and also any of this stuff needs multiple images around to delta, which means more disk space. 16:18:09 kparal: it will make things far slower than just using plain http to download the entire file. 16:18:10 i did get a finished update with --skip-broken today, but lots of packages were skipped. and i'm not sure it's going to work if i reboot =) 16:18:28 deltas also aren't very useful I would think with live images 16:18:31 Oxf13: ubuntu uses zsync for live images and it is great, you download only the differencies 16:18:32 adamw: most things should be fixed today... just NM and a few others. 16:18:40 kparal: Ubuntu's live images aren't like ours 16:19:29 * iarlyy agrees with Oxf13 16:19:30 kparal: should we hold on zsync until the open discussion? 16:19:33 Oxf13: for example brno branch have so slow line sometimes, that i really doubt it could be any slower :) 16:19:40 ok 16:19:42 * jlaska would like to dive into autoqa while psss is still around 16:20:00 kparal: if I forget, please throw something at me when we get to open discussion :) 16:20:11 jlaska: sure, go ahead 16:20:17 kparal: okay, thanks 16:20:31 # [Oxf13] - will do a build of the new autotest version for testing. 16:20:40 That was done 16:20:41 we've got a big DONE there ... thanks Oxf13! 16:20:46 np 16:20:50 and the follow-on to that point ... 16:20:51 # [jlaska + wwoods] to test latest autotest build 16:21:11 still in progress on my end ... I'm using this opportunity to help document ... 16:21:13 i would love to install it too. i am having virtual machine ready 16:21:43 #action jlaska - complete autotest setup doc and post autotest-0.11 test feedback 16:22:02 autotest? sorry what's? 16:22:20 http://fedoraproject.org/wiki/Autotest 16:22:35 I've got one more unassigned action item ... but will raise this at the end of the meeting 16:22:43 iarlyy: have you not been reading FWN religiously? i am disappointed :) 16:23:03 adamw, lately nops ;( 16:23:07 wwoods, cased on iarlyy's question ... sounds like a good opportunity for you to take it a way 16:23:15 #topic AutoQA update from wwoods 16:23:40 last week was DOCS WEEK woo 16:23:47 see http://fedoraproject.org/wiki/Category:AutoQA 16:23:52 * jlaska puts his hands in the air 16:24:12 http://fedoraproject.org/wiki/AutoQA is the main page for the Fedora AutoQA project 16:24:23 http://fedoraproject.org/wiki/Autotest has specific info about autotest and how we use it in AutoQA 16:24:38 http://fedoraproject.org/wiki/Writing_AutoQA_Hooks and http://fedoraproject.org/wiki/Writing_AutoQA_Tests explain how to write autoqa hooks and tests 16:25:06 but really, to write tests and hooks, you don't need to know anything about autoqa or autotest specifically 16:25:19 first you need a working test, or some working code to monitor for an event 16:25:28 then you write some wrapper code to make it work in AutoQA 16:25:28 * adamw waves it like he just don't care 16:25:33 ;) 16:25:42 wwoods: those are killer docs 16:25:55 if anyone's wondering why i'm waving jlaska's hand, congratulations, you're more awake than me 16:26:01 http://fedoraproject.org/wiki/Install_and_configure_autotest talks a bit about setting up your own autotest instance if you wanted to run the autoqa code on your own 16:26:17 wwoods: i'm just trying to modify autoqa to work even if you have only autotest-client, not server. i can be easier for hooks/tests developers (like me:)) 16:26:19 * iarlyy many pages to ready... Love it! oww! 16:26:36 wwoods: I'll chat with you after the meeting, but anxious for your input on how to make that page (Install_and_configure_autotest) less painful to read 16:26:41 kparal: okay, but like I said - you don't need to know anything about autoqa to write tests 16:26:44 write the test first 16:26:53 then worry about autoqa wrapper code 16:27:00 same for hooks - write the watcher first 16:27:07 * iarlyy typo s/read/ 16:27:24 wwoods, i will be interested in this in the future as well for the re-spins 16:27:27 wwoods: ok, that should be in bold text in some page :) 16:27:31 let me say that once more: you don't need autoqa or autotest to write tests. 16:27:34 at all. 16:28:19 I'll put some italics on "You should have a working test before you even start thinking about AutoQA." 16:28:42 kparal: that's probably my fault for suggesting looking at the code :( 16:28:42 :) good 16:28:56 wwoods: psss is writing some sanity tests for rpm packages. we should talk about it later when we will have time 16:29:10 jlaska: no problem, i liked to study it 16:30:11 wwoods: i think you should make it flash. and have a kitten on it. 16:30:29 hi, guys! just wanted to make clear the status of fedora test-package-sanity project 16:31:09 psss: welcome 16:31:25 psss: ? 16:31:36 the original idea came from ondrej hudlicky: to prevent dependency problems... 16:32:02 we've just started looking around... and came across the autoqa project... 16:32:31 wwoods: so they do not need to care about autoqa much, they should just code tests? 16:32:54 yes 16:33:02 ... which will be later easy to integrate 16:33:35 yes. 16:33:38 now, what/how can we help with? 16:33:45 psss: I suspect (wwoods can correct me if I get this wrong) that some of the support you'd need to initiate your tests would involve what kparal is looking at as well 16:34:21 with tests in hand, perhaps you guys might sync up on ideas for a watcher to initiate them? 16:34:41 we can probably collaborate on creating the watcher for the packages 16:35:57 wwoods: we have two watchers now right? 16:36:01 right 16:36:09 it's a lot easier to write watchers once you have some tests in mind 16:36:15 because then you know what info the tests will need 16:36:24 alright, therefore first goes the tests 16:36:26 obviously a post-koji-build watcher is going to need.. a URL to the new package(s) 16:36:47 but there might be other things you haven't thought of yet 16:37:11 so try writing the tests and then you'll have some concrete examples of what the tests need to know 16:38:13 and hopefully https://fedoraproject.org/wiki/Writing_AutoQA_Tests is a bit clearer now about the fact that you don't need any special knowledge or code from autoqa/autotest 16:38:46 kparal: I guess that ties into what you discussed earlier today ... about what conditions should rpmlint's rpmdiff test trigger a failure 16:38:56 post-koji-build may depend on our message bus 16:39:01 or some ugly email + postfix games 16:39:20 but yes, come up with the tests first, we'll worry about how to trigger them after that 16:39:29 Oxf13: the interface between the watcher and autoqa being well-defined, we can write an ugly one as a proof-of-concept 16:39:33 until such time as we have the message bus 16:39:52 and we can replace the watcher without affecting autoqa/the tests 16:40:24 psss: do you have enough information to get started on your end? 16:40:54 psss: or at least enough docs to discern what the starting point should be? 16:41:19 psss: if not, we can consult it tomorrow, just contact me :) 16:41:55 perhaps a question: when writing tests, we use BeakerLib 16:42:14 is the autotest framework be used in a similar way inside the tests? 16:42:28 not inside the test code itself 16:42:52 but the control file and test object are wrappers used by autotest to launch your test code 16:43:17 well, yes, but the test needs to log 16:43:21 autotest takes care of saving logs, test results, and other data 16:44:00 for example it defines a 'resultsdir' attribute that is the directory you should write logs to 16:44:22 does this fall into setup/precondition for the test itself ... does the test need to make sure the correct packages are available that it needs? 16:44:32 like ... 'is beaker-list installed?' 16:44:35 so for some tests we do "--logdir %s" % resultsdir 16:44:44 s/beaker-list/beaker-lib/ 16:45:21 or the wrapper can just move the logs from wherever they're written to resultsdir after the test finishes 16:47:07 Shall we wrap-up on the autoqa update for today? 16:47:13 beaker-lib does some weird mixing of harness code and convenience code for testing 16:47:27 oops sorry, keep going wwoods 16:47:27 Oxf13: where are those new packages? 16:47:30 if you're using beaker-lib for convenience in writing your test, that's your decision 16:47:39 jkeating.fedorapeople.org/infra/ 16:47:43 ty 16:47:44 and you can install beaker-lib in setup(), or package it with the test 16:48:04 it doesn't matter, we can make it work, it's not that hard, just get the test working and worry about integration later 16:48:26 just wanted to make sure, we're not duplicating with beakerlib something which is integrated in autotest already... 16:48:27 sounds like the quote for the week ... "get the test working, and worry about integration later" 16:49:00 anyway, yeah. this week in autoqa: figuring out how to get data back out of the autotest frontend/RPC code so we can populate forms for israwhidebroken.com or similar things 16:49:44 https://fedorahosted.org/autoqa/milestone/israwhidebroken.com 16:49:47 that's the roadmap 16:49:54 chromium can't open url above, ff is ok lol 16:50:18 good thing chromium isn't in Fedora then 16:50:23 sounds pretty buggy 16:50:48 wwoods: great, I hope to clean up that install guide a bit so that it meets the wwoods doc standard 16:50:52 heh 16:51:10 iarlyy: my chromium can load it 16:51:10 ok, guys, will have to go... to sum up for myself: "get the test working" ;-) 16:51:11 I'll give it a read and make additions and/or send you notes 16:51:26 psss: thanks for joining today! 16:51:33 i will contant kparal for details about our possible cooperation... 16:51:43 a yum repo will be good 16:51:48 easy to install/update 16:51:55 when kamil will not be here,, you can talk to me 16:52:03 iarlyy: definitely, that's the plan once we get Oxf13 some test feedback on these updated packges 16:52:06 jlaska: my pleasure :) 16:52:14 ok, bye, guys! 16:52:17 bye, psss 16:52:36 okay ... that's a good update on autoqa ... let's move on to some QA events this week 16:52:59 #topic Test Day Updates - Dracut 16:53:06 breakfast horizon is approaching for me. 16:53:16 thanks everyone for attending and contributing test results and/or bugs 16:53:30 I've got a draft test summary in the pipe and will send that to the list this afternoon 16:54:01 we still need feedback on bare metal (real hardware / non-kvm) ... so the existing test cases are available for any/all to contribute 16:54:21 #action jlaska - send dracut test day summary to fedora-test-list 16:54:48 any questions/comments on the dracut test day before we move on? 16:55:26 alrighty ... next up 16:55:32 #topic Test Day Updates - sectool 16:55:53 Eduard Beneš has organized a test day tomorrow for sectool 16:56:06 should it suggest pam_tally2 instead of _tally? should a default install pass level 5 ? 16:56:10 note, this is a QA sponsored test day ... but thanks to mclasen for loaning the fit'n'finish slot 16:56:33 #link https://fedoraproject.org/wiki/Test_Day:2009-09-01_Sectool 16:56:37 ooh. i didn't know it was a qa test day. it looked odd for fnf :) 16:56:38 fenris02: is this for the sectool day? 16:56:52 adamw: mclasen has been kind to loan some of his open slots 16:56:57 jlaska, for sectool- i can ask on testday too of course 16:57:30 fenris02: Hmm, sorry ... I think you are more up to speed on that that me 16:57:39 wiki page could do with an explanation of what sectool is, and possibly links to packages for F11? 16:58:06 sectool is in f10 too 16:58:13 adamw: good points 16:58:24 and a link to a live image to test with 16:58:37 do we know what version XYZ is? 16:58:52 doh! 16:59:34 let's follow-up to Eduard's fedora-test-list announcement for the event 17:00:37 adamw: you mind following-up on the list with that? 17:01:12 just to ask questions and get the info filled in? sure 17:01:29 #action adamw - to reply to sectool test day with some test day wiki improvements 17:01:32 adamw: thanks! 17:02:04 fenris02: feel free to do the same for _tally vs tally2 ... or you can join in if yo uhave time tomorrow 17:02:14 #topic Test Day Updates - sugar on a stick 17:02:18 #link https://fedoraproject.org/wiki/Test_Day:2009-09-03 17:02:26 * sdziallas waves, is about to update that page 17:02:30 this Thursday's will feature Sugar on a stick testing 17:02:42 sdziallas: I've got an email response to you inprogress 17:02:53 jlaska: I just talked to Mel, we'll put the test cases (I have them almost ready) in the semantic infra on Wednesday 17:02:57 jlaska: cool! 17:03:07 awesome 17:03:10 sdziallas: oh very nice ... I'm anxious to see how that works out 17:03:25 jlaska: I've been asking for volunteers from the Sugar-side to join us, but haven't heard anything back... but I'll try to get us some more folks 17:03:25 sdziallas: this is still using https://publictest6.fedoraproject.org/wiki right? 17:03:50 jlaska: yeah, me too... curious to test it. yup, that's what I've been directed to. 17:03:51 sdziallas: do you need any special hardware for this ... or can anyone switch to the sugar desktop (or boot live sugar image) to test? 17:04:27 jlaska: i believe the point is booting from the live image, that's what the project is about :) 17:04:29 jlaska: well, basically anybody could yum groupinstall sugar-desktop. but Sugar on a Stick is more about booting an .iso from a USB key (or in a virtual machine) 17:04:55 adamw: heh, sorry ... yeah ;) 17:04:59 adamw: yeah, right... if somebody has no other chance than yum groupinstalling, this might already help, too, though. 17:05:22 (since we're basically using the packages from Fedora for that, so if there's a bug there, it's likely that we've it in SoaS, too) 17:05:37 * jlaska sternly looks at USB key on desk 17:05:39 is a 4g usb key big enough to test? 17:05:46 the hardware question stands, though - is it expected to run on any hardware? 17:05:50 tk009: yup! even 2g should be enough... 17:05:51 (or any hardware that runs fedora, at least) 17:06:35 adamw: yeah. for any strange configurations, we decided to follow a "no-hacks"-policy, so we should be able to run SoaS on the same hardware than Fedora runs on. 17:07:27 adamw: so the same points: the more RAM, the better. hard disk not necessarily required (unless you want to test the rebootless installer, which might eat babies, though). 17:08:20 well, in case a machine isn't able to boot from USB, one would need a boot helper .iso, which just booted the USB key then... (I'll push such an image to the Sugar Labs servers today) 17:09:39 sdziallas: I'll follow-up after the meeting on that email 17:09:58 jlaska: sure, cool :) 17:10:06 sdziallas: but feel free to find adamw or myself on #fedora-qa if there are any other issues that come up 17:10:30 okay ... last Test day topic ... 17:10:37 jlaska: okey dokey... (I thought I had added #fedora-qa to my auto-login, but apparently xchat ate it) 17:10:52 no worries 17:10:54 #topic Test Day Updates - X drv week 17:11:07 adamw: so next week is the ... X test week, right? 17:11:36 i believe it is! i should really add an intel day. 17:11:52 but right now we have radeon and nouveau days on wednesday and thursday. 17:12:16 awesome, looking forward to those 17:12:20 i haven't put the pages together yet, will do so soon. it will be similar to the f11 days - just general testing of the drivers' capabilities, find out where we're at, particularly with newer stuff like nouveau modesetting 17:12:40 hopefully be able to re-use a lot of your previous test cases? 17:12:45 s/be // 17:13:05 intel drivers are worse and worse each month 17:13:31 it was much better 2 years ago 17:13:34 dpravec: this will be a good chance to figure out how bad things are prior to the beta 17:13:53 yeah, we'll be re-using test cases. 17:14:48 adamw: any issues/action you wanted to raise in the meeting today on that? 17:15:28 not really, i don't think 17:15:35 if anyone has ideas / suggestions please shoot :) 17:15:57 you're F-11 versions of these were very successful in terms of participation 17:16:37 dunno ... any updates to the xorg debugging guide needed in preparation to this? 17:16:48 any new files, or debugging boot args to consider for it 17:18:14 alrighty ... let's change over to open discussion 17:18:26 #topic Open discussion - zsync 17:18:40 #link http://zsync.moria.org.uk/ 17:18:57 kparal: so what's the take-away for zsync? 17:19:08 Oxf13: why do you think zsync etc is slower than full download? we have veery slow line, and scanning of previous image takes only 30sec 17:19:37 we = brno branch 17:19:38 because a Fedora live image is just an iso file with a squashfs imge file in it 17:20:00 and the squasfs image file isn't lined up in a way that r/zsync can take advantage of only syncing the differences 17:20:32 the data is essentially random, not useful with rsync 17:20:53 does this require some server-side data files to assist? 17:21:02 like delta-rpms and delta-isos? 17:21:20 Oxf13: haven't really tried, so I can't say. i will probably try it with some live images, just for curiosity :) but if it is the way you say it, then it really can't help 17:21:30 there's no practical way you can do a delta between two fedora-style live images, AIUI 17:21:44 kparal: squashfs is pretty heavy ;) 17:21:44 jlaska: a small .zsync file is generated on the server side and downloaded by the client, that's all 17:21:49 deltas work for installer-style Fedora images because they contain discrete package files, many of which don't change 17:22:08 i mean you will be hardly able to improve it - if all is in one squashfs image 17:22:17 alright 17:22:41 but as oxf13 says, our live images are, practically speaking, one big 600+MB file which contains a filesystem image, and if you tweak even the smallest thing in the image, the data is completely different as far as any kind of delta system is concerned 17:22:45 right, jesse? 17:22:58 that's my understanding 17:23:04 #idea Can zsync be used to improve download speed of rawhide live images? 17:23:42 i suppose theoretically you could build a filesystem image tool and a delta tool which worked in such a way that you could generate a useful delta, but i'm not aware that any such thing exists at present... 17:23:47 as I understand zsync & squashfs, zsync isn't going to help anything at all 17:24:27 adamw: i see what you mean :D 17:24:30 #agree consensus is that zsync won't improve download speed since live images are a single squashfs image. May be useful for milestone ISO downloads where delta-iso is used 17:24:40 * jlaska playing with meetbot 17:24:48 #agreed consensus is that zsync won't improve download speed since live images are a single squashfs image. May be useful for milestone ISO downloads where delta-iso is used 17:24:49 someone should test this theory, though 17:25:04 i think i will play with it tonight :) 17:25:07 is that the time-honored version of 'someone' which means 'anyone but me'? :) 17:25:10 because the idea will keep coming back unless we have some data to back/disprove the assertion 17:25:21 * adamw uses that 'someone' a lot 17:25:33 adamw: usually people use 'we' for that 17:25:37 hehe 17:25:40 #action kparal to test download zsync downloads 17:26:01 rsync actually works quite well on the normal DVD/CD images 17:26:02 well, too many 'download's in that stmt ... but you get the idea :) 17:26:13 but squashfs is going to get in the way 17:26:31 #topic Open discussion - 17:26:44 any other issues folks want to discuss in the meeting today? 17:27:00 favorite error messages? 17:27:04 missing test days? 17:27:09 :) 17:27:10 any thoughts on removing suid and using caps? 17:27:14 do you remember my ponny ? i think i can have one, but i will write about it next meeting 17:27:35 yay 17:27:39 * adamw loves ponies 17:27:47 fenris02: is that mozilla specific? 17:27:55 * jlaska looking at http://www.mozilla.org/projects/security/components/ConfigPolicy.html 17:28:12 * jlaska figures google steered me wrong 17:28:21 jlaska, no, you can remove suid from ping, traceroute, cups, etc.. and replace with caps 17:28:41 i think that's more suited to a development group discussion than QA group 17:28:45 thats interesting 17:29:00 fenris02: I think adamw hit the nail on the head there 17:29:05 it was slated to be in f12 according to the wiki so i asked :) 17:29:19 fenris02: if a larger change ... perhaps worthy of a feature page 17:29:21 er, i may be missing the question :) 17:29:31 fenris02: is there a feature for this already? 17:29:37 * jlaska queues up FeatureList 17:29:38 are you talking about https://fedoraproject.org/wiki/Features/LowerProcessCapabilities ? 17:29:41 moment, let me see if i can find it 17:30:06 quick-draw adam got it 17:30:11 hehe 17:30:23 #topic Open discussion - Features/LowerProcessCapabilities 17:30:45 so what's the question about it? 17:30:46 let me remind, we have new mailing list ! low traffic announcments about testing events! 17:30:47 # Last updated: 2009-08-31 17:30:49 # Percentage of completion: 50% 17:30:50 https://admin.fedoraproject.org/mailman/listinfo/test-announce <-- maillist page 17:31:19 adamw, it hasnt moved, and isnt in f12a yet. 17:31:21 fenris02: is this just a status check on the feature for F12? 17:31:38 jlaska, pretty much 17:32:10 seems like "too late to complete for F12, defer to F13" 17:32:21 yeah, me too 17:32:24 since we're past the feature freeze 17:32:30 50% complete ... eeek 17:32:31 it's a freaking nightmare from a qa perspective and we didn't ship it in alpha, so...ugh 17:32:40 wwoods, yeah, i was afraid of that 17:32:43 is that fact not widely known, or something? 17:32:51 it's past feature freeze. if it's not in now, it's not going in 17:32:59 jlaska, most of it's trivial, depends how much they want to implement 17:33:10 it's been discussed somewhat on -devel-list 17:33:22 i think there was some kind of suggestion of doing a small subset of the changes, but i forget the details 17:33:47 anyone interested in chasing down status on this feature w/ sgrubb and the FeatureWrangler? 17:34:20 I suppose if the work is already done for, say, the stuff that appears in a minimal install 17:34:26 then the feature could get split up 17:34:36 part#1 - F12, part#2 - F13 17:34:39 yeah 17:35:05 ping/traceroute are completely trivial. httpd is not exactly trivial. (for examples of each) 17:35:06 that's reasonable and we seem to be doing that more and more now with other features 17:35:18 but yeah, otherwise: not finished, past feature freeze, you now have 6 months to finish for F13, good luck 17:35:43 is this worth a check-in w/ the maintainer ... or does this get auto punted? 17:36:08 there are plenty on the list still that are not @ 100% complete 17:36:14 so this is a larger can of worms 17:36:27 also mtr is not useable by normal user... 17:36:31 all but 2 are @ 85% and higher 17:37:55 I think this will be an outstanding todo ... I don't know of any good ways to tackle this now (open to ideas) 17:38:18 there's quite a list of "easy" ones, but it would need rpm package changes. (eject killall modprobe ntpdate qemu route) 17:38:21 #idea should 'Lower Process Capabilities' be split into two features ... one for existing F12 work, and one for remaining F13 work 17:39:08 fenris02: do you want to reach out to sgrubb on this? 17:39:30 jlaska, sure, i'll see how i can help 17:39:34 I'll be happy to take it, unless 'someone' else would be better suited 17:39:59 fenris02: thanks, feel free to include me on the list ... I'm curious too 17:40:16 #action fenris02 - check-in w/ sgrubb on devel status of https://fedoraproject.org/wiki/Features/LowerProcessCapabilities 17:40:26 okay ... let's wrap things up today 17:40:46 please follow-up to fedora-test-list@ or #fedora-qa should any new issues come up before next week 17:40:57 thanks all for your time :) 17:41:29 yaay, we're free 17:41:30 #endmeeting