fedora-meeting
LOGS

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