18:10:16 #startmeeting Fedora Release Engineering Meeting 18:10:25 #topic roll call 18:10:38 * lmacken 18:10:44 ping: notting jeremy jwb wwoods dgilmore warren lmacken poelcat 18:10:50 * notting is here, obvs. 18:11:19 * wwoods here 18:11:26 * warren here 18:11:27 * poelcat here 18:11:49 pong 18:12:46 Alright, lets look at old business. 18:12:54 #topic Old Business 18:13:14 #topic Orphans (old business) 18:13:26 I cleaned up a ton of orphans, but left the ones that were going to cause dep issues 18:13:56 there aren't many left, I'm running the script again tos ee what's left 18:14:17 cryptix, glade2, libdockapp, qt-qsa, and tomoe 18:14:31 I'm pretty sure one of the translation folks is picking up tomoe 18:14:38 gliade2 was just recently orphaned 18:16:46 #action f13 will re-post the current orphans that will break deps to try and get some movement on them. 18:17:11 #topic gpg purging (old business) 18:17:16 this still hasn't been done, I suck. 18:17:33 gpg purging? 18:17:35 #action f13 still needs to file a ticket about gpg purging in koij 18:17:44 notting: purging of written copies of signed packages 18:17:50 the purge script is a bit dated 18:18:51 #topic Critical Path (old business) 18:19:17 There were a couple action items here, Seth was going to file a bodhi ticket, I was going to get offtrack packaged, and luke was going to report on status of bodhi changes. 18:19:29 skvidal: lmacken: ? 18:19:34 (I didn't get offtrac packaged yet) 18:19:41 f13: I filed the bodhi ticket 18:19:48 umm lemme find the number 18:19:50 one sec 18:19:56 i didn't do it on friday b/c I suck but I did it this morning 18:20:09 https://fedorahosted.org/bodhi/ticket/346 18:20:11 there you go 18:20:13 gah, I looked into the no frozen rawhide proposal, and not this one.. 18:20:17 but, it really shouldn't be much work for bodhi 18:20:26 where is this list of critical path pkgs going to be stored? 18:20:30 lmacken: comps 18:21:27 ok, cool. so yeah, it'll require some code to scrape the list out of comps... then it needs to take that into account when setting requests/karma. 18:21:59 a little bit of logic modifications, but no major code changes will be necessary 18:22:26 lmacken: so could we expect a report next week on progress? 18:22:48 f13: sure, but I don't have any spare cycles to put into it at the moment 18:22:55 ok. 18:23:14 #action now that the ticket has been filed, lmacken will report in a week's time if any progress has been made. 18:23:32 #action f13 still needs to package offtrac 18:24:18 Lets move on 18:24:24 #topic Mass Rebuild (old business) 18:24:34 Couple action items here too 18:24:49 LIsts needed to be generated/published of what hasn't been done, that's been done 18:25:10 and dgilmore was going to draft an SOP for managing rpm changes in rawhide. 18:25:14 dgilmore: get anywhere with that? 18:25:20 f13: i fail 18:25:30 s'ok. 18:25:32 I do too 18:25:49 #action dgilmore will draft an SOP (with help) for managing RPM changes in rawhide. 18:26:18 The rebuild lists are at: http://jkeating.fedorapeople.org/needed-f12-rebuilds.html and http://jkeating.fedorapeople.org/failed-f12-rebuilds.html 18:27:01 f13: how often are those lists updated, if at all? 18:27:05 I've been poking at them from time to time to see whats missing. 18:27:12 er, a note on the critpath list in comps - AFAIK there's not going to be a complete, depsolved list in comps 18:27:13 notting: in a cron job to be updated every 10 minuts or so 18:27:31 notting: the first one says when it last ran, I need to port that change over to the failed list 18:27:45 there's a list of *some* packages but all their deps are also considered critical. so you have to depsolve it out for it to be usable. 18:27:55 wwoods: I was thinking about that - the code to pull it into bodhi can depsolve it out 18:28:02 wwoods: I can commit to doing that 18:28:10 it may be a good idea to keep a static list around and regenerate that list every time comps is committed to 18:28:23 wwoods: or on every new release (ie: for changed deps) 18:28:31 ah, good point. 18:29:26 which means regenerating the list on every checkin to either comps *or* a package currently on the list. 18:29:42 eh 18:29:44 "mostly" 18:29:51 remember we don't have to be PERFECT 18:30:17 we can update the critpath list for any kind of release (alpha, beta, rc, GA) 18:30:22 and that should be PLENTY 18:30:50 if there's a couple of weeks where a new pkg is in the critpath and we (or the maintainers) don't know it - the world isn't going to end 18:31:24 we're on a tangent here, but I think the fact that comps won't contain a static list is well-understood 18:31:44 so let's continue the current topic 18:31:48 apologies for interrupting. 18:32:06 no worries 18:33:03 #info Comps listing of critical packages is not a depclosed listing. 18:33:39 that really goes to previous topic, so the meeting minutes might be a little weird, but *shrug* 18:33:50 #topic no frozen rawhide (old business) 18:34:02 I was supposed to file a bodhi ticket, but I failed to do that 18:34:08 however lmacken said he looked into this anyway 18:34:17 yeah 18:34:37 so, I thought about it a bit today, and here is what I think could potentially solve this problem: 18:34:54 - Create a new 'freezebreak' update type 18:34:59 - Allow for 2-stage pushes where bodhi simply tags updates, and writes out a partial state file. 18:35:04 18:35:04 - Create a scheduled task that takes the mashed rawhide repos, and adds them into a masher state as 'completed_repos' 18:35:08 - Give the masher the ability to resume pushes from 18:35:08 a given state file (eg: /mnt/koji/mash/updates/MASHING-rawhide-20091102) 18:35:12 - being able to push arbitrary state files makes it so 18:35:14 that normal fedora pushes won't step on the toes of rawhide 18:35:53 also, do we want releng/QA to have higher priority karma votes? 18:36:23 I think we talked before about having a little QA Team Member badge for users in the qa group 18:36:26 well, they need something like that for critical path 18:36:38 but outside of that we don't really care 18:36:42 cool 18:37:10 so yeah, that above solution wouldn't be very difficult to implement 18:37:13 purely human-informative, no effect on actual mechanisms or code.. yet 18:37:19 and I *think* it would work 18:37:41 hah cool. 18:37:48 lmacken: so then do you still need a ticket from me? 18:37:56 f13: yeah, please :) 18:37:58 ok 18:38:01 well 18:38:04 #action f13 still needs to file a bodhi ticket 18:38:08 nah, I'll just paste my notes into a new ticket 18:38:32 #action lmacken will create the ticket instead 18:38:38 :) 18:38:45 lmacken: so what do you think our chances are of having this ready by tomorrow? 18:38:50 which is the alpha freeze 18:38:59 * f13 holds a straight face 18:39:04 hahah 18:39:20 unless some magical patch writing fairy shows up at some point tonight, probably not going to happen by tomorrow 18:39:48 if this is a priority, I can try and get it done soon though 18:39:48 ok. I think we'll have to let FESCo know that no frozen rawhide is a no-go for F12 18:40:03 lmacken: no, I think if we try to rush it, we'll just end up breaking something 18:40:10 lets target F13 18:40:16 true... ok, sounds good 18:40:30 actually lets make sure everybody agrees on this 18:40:52 f13: does this mean that critical path is an infrastructure in search of an implementation for f12, as well? 18:40:52 Proposal, punt no frozen rawhide to Fedora 13 as we're at alpha freeze tomorrow 18:41:16 notting: no, critical path is independent of no frozen rawhide 18:41:29 also, I don't think critical path had a alpha freeze deadline 18:42:24 lmacken and I are already +1 on punting, I just want to make sure I'm not railroading anything here 18:43:14 =1 18:43:16 er, +1 18:43:54 no frozen rawhide bodhi ticket: https://fedorahosted.org/bodhi/ticket/347 18:44:22 f13: yeah, +1 18:45:21 alright, that's enough votes 18:45:44 #agreed No Frozen Rawhide has been punted to Fedora 13 18:46:10 #action f13 will report to FESCo this change. 18:47:24 #topic Rawhide fixup for rpm deps (old business) 18:47:36 Notting made this happen, so there isn't much to talk about here 18:47:50 although various people on various lists got a bit snippy about how it was handled. 18:48:12 it's likely to be un-fixed in the near future, as fixes come in for xz and rpm 18:48:19 yeah 18:48:24 fixes? 18:48:26 but 'near future' will be alpha 18:48:46 f13, so on the snippy part... 18:48:48 jwb: update of xz to the final version 18:48:53 notting, oh 18:49:04 f13, is there something we could have planned better? 18:49:16 perhaps not in the given timeframe... 18:49:34 jwb: landed rpm that supported xz earlier 18:49:37 we could have decided not to do it. we could have intervened earlier so that xz didn't take three+ weeks to review 18:49:37 could have punted if time wasn't enough 18:49:57 but we already have an action item for coming up with an SOP for handling these types of rpm changes 18:50:05 so that people doing the changes are aware of what we'll require 18:50:10 as will FESCo when looking at such features 18:51:06 #topic Fedora 12 Alpha (old business) 18:51:15 I had an action item to look at why images weren't showing up 18:51:23 I figured it out, and got images to show up, only they were busted for other reasons. 18:51:48 but that seems to have been cleared up as of today, and I'm generating a test compose for the QA team 18:52:13 oh crap, and it looks like I forgot to fix a pkgorder bug. *sigh* 18:52:31 #action f13 to fix issues with full pungi composes in order to produce Test Compose for Fedora 12 Alpha 18:54:00 so yeah, that'll eat up my time today. 18:54:14 we'll find what's wrong and then hopefully fix them before I have to create the release candidate later this week 18:56:46 #topic Package Signing (old business) 18:56:53 so we've gotten pretty far with our sigul testing 18:57:21 we got a bridge and server system setup in Fedora infrastructure, got the Fedora keys imported to the server, and jwb has used it (and is still using it?) to sign things for updates 18:57:21 i've done the last 2 updates pushes purely with sigul 18:57:41 whoa, excellent. 18:57:47 f13: do we want to try epel testing? 18:57:55 it's slower than sign_unsigned by a large amount 18:58:03 but then again, we're just getting it working 18:58:16 i also think we can use it to do repomd.xml signing 18:58:27 dgilmore: not yet, we do still need to rebuild and properly deploy bridge/vault 18:58:40 this week I need to met with smooge and coordinate that 18:58:55 yes 18:58:56 #action f13 will coordinate bridge/vault rebuild with smooge 18:59:42 f13: anyway we can use fedora's sigul for secondary arches? 18:59:57 theoretically? 19:00:02 f13: or will they need there own, or keep using sign_unsigned 19:00:12 dgilmore: the question becomes bandwidth 19:00:27 f13, the bridge would need access to the secondary arch koji, yes? 19:00:31 to grab the rpms 19:00:32 our sigul will exist in PHX, and if secondary arch wants to use that, our sigul would have to download all their rpms to PHX and then upload the headers back 19:00:44 jwb: it would need http access I do believe 19:00:50 yeah 19:00:52 f13: right so thats going to be very slow 19:00:58 dgilmore: it might be better for secondary arches to run their own sigul instance 19:01:17 local to where their packages are stored 19:01:27 hm 19:01:35 f13: right its just extra machines/vms that are needed 19:01:46 the benefit to 1 sigul instance is that we could use a single key per release for all arches 19:02:05 jwb: we could grant access to using the fedora key 19:02:12 i thought we were moving to a single key, period. 19:02:12 but not sure if we want to 19:02:20 but we could use one for secondary arches 19:02:33 notting: each secondary arch is to have its own key 19:03:01 well, with sigul only the server knows the passphrase. so i don't know how you'd have another instance use the same key without compromising the key passphrase 19:03:12 unless i'm confused 19:03:13 jwb: right 19:03:25 maybe we could look at a sigul proxy 19:03:31 jwb: depends on if we use sigul generated key or generate one outside of sigul and import it 19:03:36 so data transfer is minimised 19:04:07 you'd still need a bridge and vault running where the package sare 19:04:21 but I wasn't aware that we were going to extend the one Fedora key to secondary arches 19:04:31 since we have less control over those koji instances 19:04:31 f13: we are not 19:04:40 then this is moot 19:04:43 nod 19:04:53 f13: but one key for all secondary arches might be desirable 19:05:04 rather than one per arch 19:06:35 anyway, that's the status on package signing 19:07:02 I didn't have any new business, just lots of old business follow up. 19:07:02 so 19:07:06 #topic open floor 19:07:20 if there isn't anything in 3 minutes, I'll close the meeting. (We're already over time) 19:07:35 ive nothing 19:08:12 f13: is 'let them and those that depend on them burn' an acceptable orphan solution? 19:08:24 i.e., do we *need* to find owners just because something has deps? 19:08:38 notting: not exactly. If we went that route, I"d rather just strip out what depends on the orphans. 19:08:55 notting: we really shouldn't go into a release with things unowned that other packagers depend on 19:09:20 that's what i mean - at what point do we just drop them and let the broken things be broken (or also dropped) 19:10:13 notting: good question. I cc'd the owners of the things that woudl be broken by removing the orphans, we'll see if any of them respond. Probably too late to threaten recursive pruning 19:11:02 none of them seem to have any significant things that require them 19:11:15 unless i'm running repoquery wrong 19:11:57 well lets post that to the list and see what people thing. 19:12:11 #action f13 to threaten recursive blocking if orphans are not picked up by tomorrow 19:13:40 Alright, closing the meeting, thanks all! 19:13:42 #endmeeting