fedora-releng
LOGS
18:00:45 <Oxf13> #startmeeting Fedora Release Engineering Meeting
18:00:45 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:54 <Oxf13> #meetingname fedora-releng
18:00:54 <zodbot> The meeting name has been set to 'fedora-releng'
18:00:59 <Oxf13> #topic roll call
18:01:34 * dgilmore 
18:01:36 <Oxf13> ping: notting jwb rdieter lmacken dgilmore wwoods spot poelcat
18:01:41 <Oxf13> 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 <rdieter> here
18:04:24 <Oxf13> alright
18:04:57 <Oxf13> #info Present are Oxf13 dgilmore notting wwoods poelcat jwb and nirik
18:05:36 <Oxf13> #topic Old Business (SOPs)
18:06:03 <Oxf13> 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 <poelcat> Oxf13: send them my way :)
18:06:19 <Oxf13> poelcat: did you get a chance to see the SOP that lmacken wrote two weeks ago?
18:06:35 <jwb> 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 <Oxf13> http://fedoraproject.org/wiki/Bodhi_Infrastructure_SOP#Adding_a_new_pending_release
18:06:36 <poelcat> Oxf13: no, what was URL?
18:07:11 <jwb> 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 <Oxf13> jwb: awesome!
18:07:48 <poelcat> jwb: if you want to throw me rough notes, etc. i'm glad to do the wiki-fication
18:08:24 <Oxf13> #action jwb hopes to get a pushing updates SOP rough draft to poelcat next week
18:08:28 <jwb> 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 <Oxf13> On a general note, doing the SOPs has been a great help/exercise
18:10:07 <Oxf13> and other teams have noticed
18:10:16 <Oxf13> Anything else on SOPs before we move on?
18:10:57 <Oxf13> ok
18:11:10 <Oxf13> #topic Old Business (/mnt/koji storage)
18:11:16 <Oxf13> dgilmore: any updates here?
18:12:06 <dgilmore> Oxf13: we have been testing it
18:12:11 <dgilmore> its performming better
18:12:22 <dgilmore> but not a huge magnitute better
18:12:43 <dgilmore> until we can get a second unit and more spindles we wont see great improvements in speed
18:12:57 <dgilmore> AFAIK we did get the po in for FY10
18:13:06 <Oxf13> #info performance tests being performed.  It's better, but not huge magnitude better.
18:13:56 <Oxf13> dgilmore: is there anything you need from our group for more testing?
18:14:47 <dgilmore> Oxf13: i dont think so at this point
18:14:57 <Oxf13> ok.  Anything else before we move on?
18:15:01 <dgilmore> nah
18:15:49 <Oxf13> #topic Old Business (dist-git update)
18:15:58 <Oxf13> #info nothing new here this week, same story as last week
18:16:07 <Oxf13> I've got nothing new to report, any questions?
18:16:23 <jwb> i had one
18:16:51 <jwb> 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 <Oxf13> full switch over
18:17:34 <Oxf13> before that we should have a fully working build environment in stg so that we can do the testing there
18:17:43 <Oxf13> but I don't want to try supporting two different SCMs at once for official builds
18:18:15 <jwb> ok
18:18:16 <notting> 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 <notting> but i'm not sure that's enough reason to support two systems
18:18:34 <jwb> Oxf13, i ask because it impacts secondary arches as well.  not sure how to stage that in
18:18:36 <Oxf13> notting: yeah, probably.
18:18:42 <Oxf13> jwb: good point
18:18:50 <Oxf13> #info dist-git changes impact secondary arch
18:19:34 <Oxf13> alright, ready to move on?
18:19:40 <jwb> yep
18:19:57 <Oxf13> #topic Old Business (No Frozen Rawhide)
18:20:12 <Oxf13> things are moving a bit more smoothly here, and stuff is making it through updates-testing into 13
18:20:26 <Oxf13> still a little rough due to the alpha taking up a lot of attention, but still not bad
18:20:52 <jwb> there's an annoying bodhi bug right now making pushes for f13 touchy, but it's worked around ok
18:21:02 <jwb> i think lmacken said he was going to fix it on releng2 today
18:21:16 <Oxf13> goot
18:21:30 <rdieter> just wanna say I think this whole nfr thing is just awesome.
18:21:32 <jwb> though that might not happen since i have a push going
18:21:42 <Oxf13> 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 <Oxf13> jwb: so it might not be sigul related at all
18:22:06 <jwb> Oxf13, well... it could at least retry instead of fall on the floor :)
18:22:12 <Oxf13> sure.
18:22:29 <Oxf13> 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 <notting> have we seen pickup on testing of updates in bodhi for f13?
18:22:41 <Oxf13> (this is really a different topic)
18:22:58 <Oxf13> notting: I've noticed karma being added on a number of things, particularly critpath
18:23:06 <Oxf13> I don't know if it's more or  less than usual
18:23:24 <Oxf13> #info notting wonders if there has been a pickup on testing of updates in bodhi for f13
18:23:34 <jwb> 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 <Oxf13> #info Oxf13 has noticed karma being applied, not sure if it's more or less than usual.
18:25:19 <Oxf13> alright, lets move on
18:25:43 <Oxf13> #topic ticket 3420
18:25:51 <Oxf13> .rel 3420
18:25:53 <zodbot> Oxf13: #3420 (Request new compose image for translators' review) - Fedora Release Engineering - Trac - https://fedorahosted.org/rel-eng/ticket/3420
18:26:24 <Oxf13> jlaska: are you around by chance?
18:26:33 <jlaska> Oxf13: sure, what's up?
18:26:44 <Oxf13> 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 <jlaska> ah /topic
18:26:53 <Oxf13> jlaska: yeah, can you expand upon the need here?
18:27:05 <jlaska> thanks for raising this, I recommended they bring this to you guys for guidance ...
18:27:54 <jlaska> 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 <jlaska> and they noticed that the nighlies aren't always available depending on the status of the build
18:28:16 <jlaska> 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 <Oxf13> ok, so if we could just copy a nightly from that time frame and point to it, that'd be OK?
18:29:07 <jlaska> Oxf13: to answer your question, I think they'd like a live image
18:29:10 <Oxf13> does it need specific software in it, or can they install the needed software as they go?
18:29:33 <jlaska> Oxf13: yeah, I think copying a successful nightly to another location after translations are complete would do
18:30:06 <jlaska> 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 <Oxf13> yeah, sounds good
18:30:35 <Oxf13> #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 <Oxf13> #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 <notting> question added to ticket
18:31:02 <Oxf13> #action jlaska to update the ticket with the needed info
18:31:06 <Oxf13> #undo
18:31:07 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x283471d0>
18:31:10 <jlaska> notting: oh, thanks
18:31:13 * jlaska loving that #undo :)
18:31:20 <Oxf13> #info notting updated the ticket with the questions needed answering
18:32:53 <Oxf13> Ok, so that probably covers this topic
18:33:08 <Oxf13> We'll revisit it as long as the meeting keyword is still there
18:33:19 <Oxf13> #topic F13 Alpha
18:33:25 <Oxf13> #info Alpha slipped by a week
18:33:35 <Oxf13> #info RC4 was produced and posted, testing currently happening
18:33:43 <Oxf13> https://fedoraproject.org/wiki/Test_Results:Fedora_13_Alpha_RC4_Install
18:33:54 <Oxf13> https://fedoraproject.org/wiki/Test_Results:Fedora_13_Alpha_RC4_Desktop
18:34:06 <Oxf13> from what it looks like, I have strong confidence that RC4 will be The One
18:35:30 <Oxf13> 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 <dgilmore> Oxf13: sounds good
18:36:47 <Oxf13> one question I have, which spins to produce as part of alpha?
18:37:20 <Oxf13> #info What spins will we produce for Alpha?
18:37:40 <Oxf13> 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 <dgilmore> but let the spins owners make sure they work
18:38:16 <Oxf13> this is something we should communicate better with the spin sig
18:38:17 <dgilmore> and we do spins for beta and ga
18:38:19 <Oxf13> set an expectation
18:38:34 <Oxf13> #action Oxf13 will communicate with spin sig and try to set an expectation
18:38:44 <rdieter> dgilmore: I think so too
18:38:58 <poelcat> what is the downside of doing spins for Alpha?
18:39:19 <dgilmore> 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 <poelcat> dgilmore: oh, i always understood them to be best effort, but never hold up release
18:39:42 <dgilmore> it uses more disk/bandwith/time
18:39:50 <Oxf13> poelcat: there are, but there is no expectation that we'd produce the spins at Alpha/Beta milestones
18:40:10 <poelcat> hm
18:40:10 <Oxf13> basically there just isn't an expectation set here
18:40:21 <poelcat> for some reason i was under the impression we did
18:40:30 <Oxf13> previous releases we've done one or two spins at alpha, sometimes none
18:40:33 <Oxf13> ditto beta
18:41:01 <poelcat> if that is the case, won't some spins owners have the expectation we would do it this time?
18:41:09 <notting> i agree - we should define some expectation and document it
18:41:12 * poelcat not following logic :)
18:41:31 <Oxf13> poelcat: it wasn't always the same spins done
18:42:19 <Oxf13> so I'll follow up on this
18:42:27 <poelcat> https://fedoraproject.org/wiki/Category:Spins_Fedora_13
18:42:43 <poelcat> #info https://fedoraproject.org/wiki/Category:Spins_Fedora_13
18:42:44 <Oxf13> I'm really not going to be happy with doing every spin for Alpha
18:42:55 <Oxf13> 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 <nirik> yeah, personally I think the nightlys are fine for testing, but other spin owners might not.
18:44:06 <nirik> 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 <Oxf13> alright, anything else on this topic?
18:44:18 <Oxf13> nirik: that's a good idea
18:44:33 <Oxf13> #info could mention nightly composes when announcing the Alpha
18:45:44 <Oxf13> Alright lets move on
18:45:55 <Oxf13> er.. well, I'm out of topics
18:46:00 <Oxf13> #topic Open Floor
18:46:04 <Oxf13> oh!
18:46:08 <Oxf13> #topic releng additions
18:46:21 <Oxf13> Till Mass has offered to help with tagging requests
18:46:32 <Oxf13> so I've granted him rights and showed him the SOPs for how to do it
18:46:44 <Oxf13> 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 <Oxf13> #info Till Mass is now helping with tag request
18:47:16 <Oxf13> #info Oxf13 wants to give a big thank you to Till for stepping up and really kicking butt
18:47:40 <Oxf13> I've also been given some internal RHT resources to help me out with fedora releng
18:48:01 <Oxf13> Nick Petrov will be helping me out
18:48:04 <dgilmore> im going to add him to the epel tagging group also
18:48:12 <dgilmore> till that is
18:48:14 <Oxf13> 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 <Oxf13> 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 <Oxf13> #info Nick Petrov to help out with Fedora releng work as well
18:49:04 <Oxf13> All the more reason to keep our SOPs in good shape
18:50:10 <dgilmore> 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 <Oxf13> dgilmore: interesting.  Is that something you think we should copy in Fedora?
18:50:58 <dgilmore> Oxf13: it may be something to look at to grant tagging access only
18:51:18 <dgilmore> it certainly helps me feel better about giving the access out
18:51:20 <Oxf13> nod
18:51:30 <dgilmore> it greatly reduces the damage that can be done
18:51:36 <Oxf13> #info could use koji groups to grant tag access instead of koji admin rights
18:51:48 <Oxf13> I have another related topic
18:51:55 <Oxf13> #topic Critical Path Updates
18:52:08 <Oxf13> F13 critpath updates require karma to get pushed, and that karma has to come from our group or QA
18:52:19 <Oxf13> #info F13 critpath updates require karma to get pushed, and that karma has to come from our group or QA
18:52:51 <Oxf13> QA is working on ways to grow their group, the people with rights to grant that karma
18:52:56 <Oxf13> our group could grow here too
18:53:32 <Oxf13> 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 <Oxf13> until such time we feel that the person is ready for releng status
18:54:02 <Oxf13> ti's a harder problem to answer for releng though since we do more than just test packages
18:54:22 <Oxf13> but if any of you want to think about ways we can grow our group, I'd love to hear them.
18:54:24 <wwoods> 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 <wwoods> I have a feeling the mentoring process and requirements for accepting new members will be identical for qa & rel-eng
18:55:28 <Oxf13> yeah they could be
18:55:41 <wwoods> very, very similar anyway. two subclasses of the same base.
18:56:07 <wwoods> so obviously we should share responsibility on writing that junk up.
18:56:19 <nirik> I have noticed bodhi notes "cvsadmin" as well... does that count against qa/rel-eng ? or ?
18:56:32 <wwoods> 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 <wwoods> is there going to be a corresponding group of rel-eng people who can do the same?
18:56:51 <Oxf13> nirik: I don't think it does, but I think it just picks the first group it sees a person in
18:57:00 <nirik> ok, just curious.
18:57:08 <Oxf13> 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 <Oxf13> #info Would like to see some ideas on growing releng group
18:57:39 <Oxf13> #info Mentoring process and requirements will be very very similar between releng and qa groups.  need to work together
18:57:54 <wwoods> so what's the FAS group used for rel-eng in this context?
18:57:54 <Oxf13> wwoods: yes, that is the rel-eng group currently
18:58:30 <wwoods> 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 <wwoods> dunno if 'rel-eng' gets used for other stuff already
18:59:27 <wwoods> 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 <wwoods> or are we shooting for multiple reviewers for each thing that needs checking
19:00:00 <Oxf13> the releng group is used for a few things, but I'm not sure what all
19:00:11 <Oxf13> there is /some/ form of division, eg we care about how anaconda is used to compose images
19:00:19 <Oxf13> QA cares a bit more about how those images turn out
19:00:37 <Oxf13> 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 <Oxf13> 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 <Oxf13> and since releng had been the ones doing the freeze break approvals
19:02:43 <wwoods> 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 <Oxf13> that seems reasonable
19:03:40 <Oxf13> and a good guideline, although i don't think we should limit each group to each kind of testing
19:03:47 <wwoods> 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 <Oxf13> just more of a general expectation
19:04:01 <wwoods> and obviously installing and testing a package constitutes some de facto integrity/sanity checking
19:04:05 <wwoods> but yeah
19:04:37 <wwoods> it's not a clear-cut division of labor but that's the general idea
19:05:05 <Oxf13> good stuff
19:05:33 <wwoods> so, woo
19:06:32 <wwoods> I should mention that QA is in the process of discussing and researching a general test plan for new updates
19:06:36 <wwoods> see https://fedoraproject.org/wiki/User:Kparal/Proposal:Package_update_acceptance_test_plan
19:06:54 <wwoods> and https://fedoraproject.org/wiki/User:Kparal/Proposal:Package_update_policy for the update policy ideas
19:07:04 <wwoods> https://fedoraproject.org/wiki/User:Kparal/Package_update_approaches summarizes how other distros do it
19:07:54 <Oxf13> neat!
19:07:56 <wwoods> rel-eng would probably be most interested in the policy discussion
19:07:59 <Oxf13> yep
19:08:17 <wwoods> as I said, it's ongoing, but there's what we're discussing
19:08:26 <wwoods> big ups to kparal for that stuff
19:08:46 <Oxf13> #info any releng effort to grow the group should work with the QA efforts linked in this meeting
19:09:01 <Oxf13> anything else we want to discuss on this topic?
19:09:40 <Oxf13> alright
19:09:43 <Oxf13> #topic open floor
19:09:51 <Oxf13> anybody got something for the meeting?
19:11:47 <Oxf13> Looks like no, so thanks all for coming1
19:11:48 <Oxf13> !
19:11:53 <Oxf13> #endmeeting