18:00:45 #startmeeting Fedora Release Engineering Meeting 18:00:45 Meeting started Fri Feb 26 18:00:45 2010 UTC. The chair is Oxf13. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:47 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:54 #meetingname fedora-releng 18:00:54 The meeting name has been set to 'fedora-releng' 18:00:59 #topic roll call 18:01:34 * dgilmore 18:01:36 ping: notting jwb rdieter lmacken dgilmore wwoods spot poelcat 18:01:41 and anybody else I forgot 18:01:42 * notting is here 18:01:46 * wwoods appears in a burst of flame 18:01:59 * nirik is lurking around in the cheap seats in the back. 18:02:14 * poelcat here 18:02:19 * jwb here 18:02:29 here 18:04:24 alright 18:04:57 #info Present are Oxf13 dgilmore notting wwoods poelcat jwb and nirik 18:05:36 #topic Old Business (SOPs) 18:06:03 So i did not get a SOP written up this week. I have lots of half complete gnotes with some steps in them, so maybe I can return 2 next week 18:06:17 Oxf13: send them my way :) 18:06:19 poelcat: did you get a chance to see the SOP that lmacken wrote two weeks ago? 18:06:35 i sat down to write the updates one last week and realized that a few things i do for it actually relied on code that was only sitting on my machine 18:06:36 http://fedoraproject.org/wiki/Bodhi_Infrastructure_SOP#Adding_a_new_pending_release 18:06:36 Oxf13: no, what was URL? 18:07:11 i think i have all that code in various upstream repos now, so hopefully i can get the SOP done by next week 18:07:34 jwb: awesome! 18:07:48 jwb: if you want to throw me rough notes, etc. i'm glad to do the wiki-fication 18:08:24 #action jwb hopes to get a pushing updates SOP rough draft to poelcat next week 18:08:28 poelcat, i might do that. there are lots of tweaks and variations, so let me draft up something here and maybe we can work it into the wiki together 18:08:40 * Oxf13 plays task master 18:09:01 On a general note, doing the SOPs has been a great help/exercise 18:10:07 and other teams have noticed 18:10:16 Anything else on SOPs before we move on? 18:10:57 ok 18:11:10 #topic Old Business (/mnt/koji storage) 18:11:16 dgilmore: any updates here? 18:12:06 Oxf13: we have been testing it 18:12:11 its performming better 18:12:22 but not a huge magnitute better 18:12:43 until we can get a second unit and more spindles we wont see great improvements in speed 18:12:57 AFAIK we did get the po in for FY10 18:13:06 #info performance tests being performed. It's better, but not huge magnitude better. 18:13:56 dgilmore: is there anything you need from our group for more testing? 18:14:47 Oxf13: i dont think so at this point 18:14:57 ok. Anything else before we move on? 18:15:01 nah 18:15:49 #topic Old Business (dist-git update) 18:15:58 #info nothing new here this week, same story as last week 18:16:07 I've got nothing new to report, any questions? 18:16:23 i had one 18:16:51 when it's ready for use, are we going to do a full switch over, or do some 'beta' trials with a few packages first? 18:17:11 full switch over 18:17:34 before that we should have a fully working build environment in stg so that we can do the testing there 18:17:43 but I don't want to try supporting two different SCMs at once for official builds 18:18:15 ok 18:18:16 my only concern with that would be that a significant percentage (likely majority) of packagers aren't going to look at it until it drops on their head 18:18:26 but i'm not sure that's enough reason to support two systems 18:18:34 Oxf13, i ask because it impacts secondary arches as well. not sure how to stage that in 18:18:36 notting: yeah, probably. 18:18:42 jwb: good point 18:18:50 #info dist-git changes impact secondary arch 18:19:34 alright, ready to move on? 18:19:40 yep 18:19:57 #topic Old Business (No Frozen Rawhide) 18:20:12 things are moving a bit more smoothly here, and stuff is making it through updates-testing into 13 18:20:26 still a little rough due to the alpha taking up a lot of attention, but still not bad 18:20:52 there's an annoying bodhi bug right now making pushes for f13 touchy, but it's worked around ok 18:21:02 i think lmacken said he was going to fix it on releng2 today 18:21:16 goot 18:21:30 just wanna say I think this whole nfr thing is just awesome. 18:21:32 though that might not happen since i have a push going 18:21:42 jwb: oh, and yeah, the sigul crashes do seem to be fas related, and #fedora-infra has seen it happen elsewhere 18:21:46 * nirik hopes it will result in a nice f13. 18:21:48 jwb: so it might not be sigul related at all 18:22:06 Oxf13, well... it could at least retry instead of fall on the floor :) 18:22:12 sure. 18:22:29 jwb: I think we are going to modify fas2.py on the bridge to get more details of what it's getting from the server 18:22:32 have we seen pickup on testing of updates in bodhi for f13? 18:22:41 (this is really a different topic) 18:22:58 notting: I've noticed karma being added on a number of things, particularly critpath 18:23:06 I don't know if it's more or less than usual 18:23:24 #info notting wonders if there has been a pickup on testing of updates in bodhi for f13 18:23:34 from where i stand the biggest (only?) detriment of NFR is that now secondary arches have two active development targets to shadow. i know the ppc builders can't keep up. 18:23:40 #info Oxf13 has noticed karma being applied, not sure if it's more or less than usual. 18:25:19 alright, lets move on 18:25:43 #topic ticket 3420 18:25:51 .rel 3420 18:25:53 Oxf13: #3420 (Request new compose image for translators' review) - Fedora Release Engineering - Trac - https://fedorahosted.org/rel-eng/ticket/3420 18:26:24 jlaska: are you around by chance? 18:26:33 Oxf13: sure, what's up? 18:26:44 so it looks like the translators want an image composed. I'm not sure what would be different from the nightly live image, or boot.iso or what. 18:26:44 ah /topic 18:26:53 jlaska: yeah, can you expand upon the need here? 18:27:05 thanks for raising this, I recommended they bring this to you guys for guidance ... 18:27:54 I don't have all the details handy at the moment ... but my understanding is that they wanted to use a live image for i18n testing 18:28:10 and they noticed that the nighlies aren't always available depending on the status of the build 18:28:16 so I think they just needed a URL they could rely on 18:28:25 * jlaska trying to locate mail thread to see if they had specific content needs 18:28:58 ok, so if we could just copy a nightly from that time frame and point to it, that'd be OK? 18:29:07 Oxf13: to answer your question, I think they'd like a live image 18:29:10 does it need specific software in it, or can they install the needed software as they go? 18:29:33 Oxf13: yeah, I think copying a successful nightly to another location after translations are complete would do 18:30:06 Oxf13: I'm not sure on the software, good question. Should we drop that back into the ticket seeing if they default desktop live image environment meets their needs? 18:30:22 yeah, sounds good 18:30:35 #info Should be able to copy a known good nightly live image for this need 18:30:49 * jlaska updates the ticket with question about desired software 18:30:50 #info Need to know if the software on the nightly image is enough for the translators, or if they can install missing software OK 18:30:58 question added to ticket 18:31:02 #action jlaska to update the ticket with the needed info 18:31:06 #undo 18:31:07 Removing item from minutes: 18:31:10 notting: oh, thanks 18:31:13 * jlaska loving that #undo :) 18:31:20 #info notting updated the ticket with the questions needed answering 18:32:53 Ok, so that probably covers this topic 18:33:08 We'll revisit it as long as the meeting keyword is still there 18:33:19 #topic F13 Alpha 18:33:25 #info Alpha slipped by a week 18:33:35 #info RC4 was produced and posted, testing currently happening 18:33:43 https://fedoraproject.org/wiki/Test_Results:Fedora_13_Alpha_RC4_Install 18:33:54 https://fedoraproject.org/wiki/Test_Results:Fedora_13_Alpha_RC4_Desktop 18:34:06 from what it looks like, I have strong confidence that RC4 will be The One 18:35:30 I don't want to spend the week slip thinking of more things we coudl put in the alpha, instead I want to get it staged ASAP and move on 18:35:56 Oxf13: sounds good 18:36:47 one question I have, which spins to produce as part of alpha? 18:37:20 #info What spins will we produce for Alpha? 18:37:40 Right now I haven't made any spins, I consider the Desktop and KDE live images to be just live images, nto spins 18:37:53 * dgilmore thinks that we should not do any 18:38:04 but let the spins owners make sure they work 18:38:16 this is something we should communicate better with the spin sig 18:38:17 and we do spins for beta and ga 18:38:19 set an expectation 18:38:34 #action Oxf13 will communicate with spin sig and try to set an expectation 18:38:44 dgilmore: I think so too 18:38:58 what is the downside of doing spins for Alpha? 18:39:19 poelcat: it could hold things up if they blow up 18:39:23 * poelcat thought there is a page and wiki category for accepted spins of the release 18:39:39 dgilmore: oh, i always understood them to be best effort, but never hold up release 18:39:42 it uses more disk/bandwith/time 18:39:50 poelcat: there are, but there is no expectation that we'd produce the spins at Alpha/Beta milestones 18:40:10 hm 18:40:10 basically there just isn't an expectation set here 18:40:21 for some reason i was under the impression we did 18:40:30 previous releases we've done one or two spins at alpha, sometimes none 18:40:33 ditto beta 18:41:01 if that is the case, won't some spins owners have the expectation we would do it this time? 18:41:09 i agree - we should define some expectation and document it 18:41:12 * poelcat not following logic :) 18:41:31 poelcat: it wasn't always the same spins done 18:42:19 so I'll follow up on this 18:42:27 https://fedoraproject.org/wiki/Category:Spins_Fedora_13 18:42:43 #info https://fedoraproject.org/wiki/Category:Spins_Fedora_13 18:42:44 I'm really not going to be happy with doing every spin for Alpha 18:42:55 poelcat: no need to #info it, meetbot will pick up the raw link 18:43:20 * poelcat isn't arguing either way to we just need to set clear expectations and criteria for what is produced or isn't for alpha 18:43:37 yeah, personally I think the nightlys are fine for testing, but other spin owners might not. 18:44:06 perhaps we could communicate in the Alpha announcement about the nightlys for spin testing at least? otherwise people won't see them and they will get less testing. 18:44:14 alright, anything else on this topic? 18:44:18 nirik: that's a good idea 18:44:33 #info could mention nightly composes when announcing the Alpha 18:45:44 Alright lets move on 18:45:55 er.. well, I'm out of topics 18:46:00 #topic Open Floor 18:46:04 oh! 18:46:08 #topic releng additions 18:46:21 Till Mass has offered to help with tagging requests 18:46:32 so I've granted him rights and showed him the SOPs for how to do it 18:46:44 he's really been kicking butt with keeping up on the tag requests, and it's good to have coverage in his timezone 18:46:56 #info Till Mass is now helping with tag request 18:47:16 #info Oxf13 wants to give a big thank you to Till for stepping up and really kicking butt 18:47:40 I've also been given some internal RHT resources to help me out with fedora releng 18:48:01 Nick Petrov will be helping me out 18:48:04 im going to add him to the epel tagging group also 18:48:12 till that is 18:48:14 and I'll be getting him up to speed on the things we do and how we do them 18:48:27 * nirik nods. till offered to help with epel tags... I provided info on the epel-devel list. 18:48:31 I hope to have Nick start doing more of the day to day stuff, so I can do more of the programming work necessary for things like dist-git 18:48:47 #info Nick Petrov to help out with Fedora releng work as well 18:49:04 All the more reason to keep our SOPs in good shape 18:50:10 Oxf13: epel uses a koji group. it means the tagger doesnt need to be an admin and doesnt have to force the tag into the override 18:50:29 dgilmore: interesting. Is that something you think we should copy in Fedora? 18:50:58 Oxf13: it may be something to look at to grant tagging access only 18:51:18 it certainly helps me feel better about giving the access out 18:51:20 nod 18:51:30 it greatly reduces the damage that can be done 18:51:36 #info could use koji groups to grant tag access instead of koji admin rights 18:51:48 I have another related topic 18:51:55 #topic Critical Path Updates 18:52:08 F13 critpath updates require karma to get pushed, and that karma has to come from our group or QA 18:52:19 #info F13 critpath updates require karma to get pushed, and that karma has to come from our group or QA 18:52:51 QA is working on ways to grow their group, the people with rights to grant that karma 18:52:56 our group could grow here too 18:53:32 one thought would be to have people who want to help provide karma on their own, and an existing releng "mentor" could ack that karma with their own positive karma 18:53:43 until such time we feel that the person is ready for releng status 18:54:02 ti's a harder problem to answer for releng though since we do more than just test packages 18:54:22 but if any of you want to think about ways we can grow our group, I'd love to hear them. 18:54:24 it's challenging but totally sensible to require that a) important things get tested, b) we define some baseline procedures for testing, and c) we have some minimal procedure to be sure people are aware of the proper procedures 18:55:14 I have a feeling the mentoring process and requirements for accepting new members will be identical for qa & rel-eng 18:55:28 yeah they could be 18:55:41 very, very similar anyway. two subclasses of the same base. 18:56:07 so obviously we should share responsibility on writing that junk up. 18:56:19 I have noticed bodhi notes "cvsadmin" as well... does that count against qa/rel-eng ? or ? 18:56:32 as I understand it, we've been talking about using the FAS 'qa' group as the group of people qualified to provide valid karma for purposes of critpath stuff 18:56:47 is there going to be a corresponding group of rel-eng people who can do the same? 18:56:51 nirik: I don't think it does, but I think it just picks the first group it sees a person in 18:57:00 ok, just curious. 18:57:08 nirik: it does do the right thing when I give karma, eg counting it as releng or qa, but it lists me as "cvsadmin" 18:57:20 #info Would like to see some ideas on growing releng group 18:57:39 #info Mentoring process and requirements will be very very similar between releng and qa groups. need to work together 18:57:54 so what's the FAS group used for rel-eng in this context? 18:57:54 wwoods: yes, that is the rel-eng group currently 18:58:30 the 'qa' group is otherwise unused, and this is kind of the most obvious place where we need to grow/track the QA group, so it's clear we should use it for this 18:58:30 * Oxf13 verifies 18:58:42 dunno if 'rel-eng' gets used for other stuff already 18:59:27 do you see there being a division of labor here? like qa verifies functionality, rel-eng verifies, I dunno, package sanity / integrity 18:59:55 or are we shooting for multiple reviewers for each thing that needs checking 19:00:00 the releng group is used for a few things, but I'm not sure what all 19:00:11 there is /some/ form of division, eg we care about how anaconda is used to compose images 19:00:19 QA cares a bit more about how those images turn out 19:00:37 but as far as the critpath goes, really what we're providing is a smoke test of operation, avoiding the brown paper bag 19:01:25 I think we named releng and qa as groups with super karma powers so that QA alone wasn't slapped withthe task 19:01:35 and since releng had been the ones doing the freeze break approvals 19:02:43 I think the way things are currently structured, you could say that releng is responsible for package & repo integrity/sanity (i.e. making sure the packages don't break deps) and qa is responsible for functional testing of the package itself 19:03:24 that seems reasonable 19:03:40 and a good guideline, although i don't think we should limit each group to each kind of testing 19:03:47 right - it would be really, really good practice for releng to do at least basic functional sanity checks (even though QA will be responsible in the end) 19:03:51 just more of a general expectation 19:04:01 and obviously installing and testing a package constitutes some de facto integrity/sanity checking 19:04:05 but yeah 19:04:37 it's not a clear-cut division of labor but that's the general idea 19:05:05 good stuff 19:05:33 so, woo 19:06:32 I should mention that QA is in the process of discussing and researching a general test plan for new updates 19:06:36 see https://fedoraproject.org/wiki/User:Kparal/Proposal:Package_update_acceptance_test_plan 19:06:54 and https://fedoraproject.org/wiki/User:Kparal/Proposal:Package_update_policy for the update policy ideas 19:07:04 https://fedoraproject.org/wiki/User:Kparal/Package_update_approaches summarizes how other distros do it 19:07:54 neat! 19:07:56 rel-eng would probably be most interested in the policy discussion 19:07:59 yep 19:08:17 as I said, it's ongoing, but there's what we're discussing 19:08:26 big ups to kparal for that stuff 19:08:46 #info any releng effort to grow the group should work with the QA efforts linked in this meeting 19:09:01 anything else we want to discuss on this topic? 19:09:40 alright 19:09:43 #topic open floor 19:09:51 anybody got something for the meeting? 19:11:47 Looks like no, so thanks all for coming1 19:11:48 ! 19:11:53 #endmeeting