20:00:55 <pwhalen> #startmeeting
20:00:55 <zodbot> Meeting started Wed May 16 20:00:55 2012 UTC.  The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:55 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:01:04 <pwhalen> #chair pwhalen jonmasters bconoboy ctyler pbrobinson
20:01:04 <zodbot> Current chairs: bconoboy ctyler jonmasters pbrobinson pwhalen
20:01:22 <pwhalen> #topic 1) Release of the Fedora 17 Beta - Are there any remaining issues blocking the release?
20:02:03 <djdelorie> please re-post the etherpad url for the alpha/beta vfad
20:02:33 * jonmasters believes we can ship beta
20:02:46 <pwhalen> does anyone have the link for the etherpad doc handy?
20:03:12 <bconoboy> http://etherpad.proximity.on.ca:9001/p/Fedora_ARM-VFAD-2012-05-11
20:03:27 <jcapik1> do we have a working 3.x kernel for Panda?
20:03:50 <bconoboy> no.
20:03:55 <jonmasters> no, however that does not need to block release
20:04:11 * djdelorie never got usb working on TS but that's likely not a blocker either
20:04:15 <jonmasters> we have a 3.x kernel that works on Beagle. Panda will be unsupported in the beta with the existing kernel
20:04:24 <djdelorie> given that the usb *ssd* worked
20:04:26 <jcapik1> it's not a blocker, but it would be nice to have
20:04:47 <bconoboy> let's treat the panda kernel issue as a high priority post-beta issue.
20:04:51 <jonmasters> #agreed it would be nice to support Panda but there is an upstream kernel bug that needs resolution - fix for GA
20:05:13 <djdelorie> agreed on skipping TS usb bug for now?
20:05:27 <bconoboy> +1 on skipping TS usb bug for now
20:05:31 * jonmasters will spend sufficient time today completing my investigation and sending it on to upstream for analysis
20:05:42 <jonmasters> (IOW making it someone else's problem)
20:05:46 <djdelorie> it means I couldn't test the "auto mounting of removable media" beta bullet
20:06:04 <jonmasters> I can confirm removable media works on TS
20:06:10 <bconoboy> believe that bullet is only valid for X-based images which does not include TS
20:06:11 <jonmasters> using the SD Card slot
20:06:17 <djdelorie> anyone check the auto-check-for-updates bullet?
20:06:34 <jcapik1> jonmasters: can anyone help with that?
20:06:51 <jonmasters> jcapik1: sure, if you've got hardware and know how to debug a kernel
20:07:04 <jonmasters> it'll reliably panic on boot
20:07:08 <djdelorie> do our images have the official firstboot in them?
20:07:29 <jonmasters> djdelorie: can we turn it around this way...Does anyone have any objections to shipping F17 beta?
20:07:38 <djdelorie> the only other thing to check is to see if a clean shutdown shuts down LVM/raid arrays
20:07:42 <jcapik1> jonmasters: you know .... I have a working 3.x kernel from ubuntu ... how that comes, that they managed to make it working?
20:07:50 <djdelorie> I'm just going over the pre-agreed-on alpha/beta list
20:08:11 <ctyler> jonmasters: no objection, but I think we should make a point of testing a few skipped things before GA
20:08:13 <jonmasters> jcapik1: different config. I can boot a kernel with a different config - e.g. all debug options on. It's a percpu bug I think
20:08:21 <jonmasters> ctyler: AGREE 100%
20:08:38 <jcapik1> jonmasters: ok .... I could also look at the issue tomorrow in the office
20:08:47 <jonmasters> jcapik1: I'll send an update TODAY on Panda. So others can pick up that baton from me
20:08:50 <djdelorie> in that case, the RIGHT thing to do is to agree to change the alpha/beta list so that we "happen" to pass everything
20:09:33 * djdelorie has no philosophical reason to not release a beta, just wants to see it properly documented
20:09:48 <bconoboy> +1 djdelorie
20:09:51 * jonmasters suggests that we have made a good effort to verify the release criteria. I suggest we ship the beta and review what we missed/consider post-mortem considerations for future improvement
20:10:19 <bconoboy> does anybody object to jonmasters' suggestion?
20:10:21 <jonmasters> IOW we do not change the list, we just document what we failed to meet in review
20:10:44 <dmarlin> how will the beta be tagged (in koji, etc.) so we know what went into it?
20:11:01 <dgilmore> buenos dias amigos
20:11:11 <bconoboy> hola release engineer
20:11:34 <djdelorie> better documentation of what/how was tested would be nice.  For example, I did test that simple partitions were cleanly unmounted, just not LVM/raid (I couldn't mount a second disk due to the usb problem, and didn't have time to set up an iscsi volume for it)
20:11:34 <dgilmore> dmarlin: we could make a snapshot tag. though we do not do that on primary
20:12:19 <dmarlin> dgilmore: how are betas tagged or otherwise marked on primary?
20:12:31 <dmarlin> (how could they later be reproduced?)
20:12:41 <dgilmore> dmarlin: managed via bodhi
20:12:54 <dgilmore> dmarlin: we lock down what gets tagged into f17
20:13:05 <dgilmore> limit it to only release blockers
20:13:19 <dmarlin> dgilmore: ok, so how are _we_ going to handle it (fedora-arm)?
20:13:20 <jonmasters> right, so at the point of beta the spiggot is turned off and things go through bodhi
20:13:51 <dgilmore> dmarlin: really its just a snapshot in time.  the only thing we will release is the images
20:14:10 <dgilmore> there is no Fedora tree since we do not have anaconda install images
20:14:15 * jonmasters thinks there's some value to a special tag, but we don't need to go too crazy for beta. Most people using it are already involved in e.g. #fedora-arm and will probably do an yum upgrade to the latest versions anyway
20:14:31 <dgilmore> the Everything repo is development/17  that gets updated automatically nightly
20:14:50 <dgilmore> we could make a f17-beta tag that shows the packageset snapshot
20:14:55 * djdelorie suggests "rpm -qa" in the wiki under "what we did for beta"
20:15:15 <fossjon> +1 rpm -qa
20:15:30 <djdelorie> betas are too transient to worry about reproducing them later
20:15:31 <dmarlin> dgilmore: ok, I just think some way to identify what went into this would be nice, in case we later want to know.
20:15:35 <jonmasters> #idea most people want the beta to have a known-good pre-built image with some testing. The images we have meet that criteria. Most people will want to upgrade packages and get F17 updates anyway. Therefore, take no special action to tag beta at this stage.
20:15:41 <ctyler> djdelorie: simple and elegant :-)
20:16:02 <djdelorie> +1 jonmasters
20:16:05 <ctyler> +1 djdelorie and jonmasters
20:16:11 <ctyler> (i.e., wiki list only)
20:16:15 * jonmasters suggests just doing a koji repo query and document all current versions used for the images
20:16:26 <dmarlin> thanks
20:16:36 <jonmasters> i.e. not just image content, but also the versions of all other packages that might have been picked up or otherwise used in the beta process
20:16:57 <djdelorie> essentially the same thing, just more global.  I'm OK with that
20:17:00 <jonmasters> that's easy enough to do for the 17 devel repo, right. I'm sure dgilmore could stash that on the wiki in 10 seconda
20:17:13 <djdelorie> as long as they haven't changed since bconoboy's images :-)
20:17:23 <dgilmore> its easier to just clone the f17 tag to f17-beta
20:17:34 <jonmasters> dgilmore: then let's do that
20:17:42 <jonmasters> it's easy to remove the tag later
20:18:16 <jonmasters> so shall we release the current nightlies as beta? And for Panda we won't release an image. Right?
20:18:32 <jonmasters> how about we release beta tomorrow? Gives some time to sync bits to mirrors
20:18:41 <djdelorie> ok with me
20:18:46 <bconoboy> if we're going with the images currently available via yum I can do one last update to ensure they match.
20:18:59 <dmarlin> will we need to test them again?
20:19:09 <jonmasters> yes
20:19:11 <bconoboy> believe we should. things have happened since friday.
20:19:17 <dmarlin> agreed
20:19:20 <pwhalen> +1
20:19:22 <jcapik1> we should
20:19:35 <jonmasters> I don't want to "just upgrade" beyond that. I'm ok with "just upgrade" if we're going to re-test each one this afternoon
20:19:39 <bconoboy> (I am, infact, regenerating some images right now)
20:20:05 <jonmasters> so if dgilmore creates the beta tag right now, pull that in and then let's leave it alone and not change the beta images again
20:20:18 <bconoboy> sounds good
20:20:19 <dgilmore> jonmasters: its created
20:20:31 <jonmasters> we know from history that "we'll just..." results in images that don't work :)
20:20:41 <jonmasters> dgilmore: thanks
20:21:07 <bconoboy> dgilmore: after the meeting let's decide where to put these images
20:21:17 <jonmasters> ok, so bconoboy will ping us when there are more images. If they boot and seem to work tonight, we ship tomorrow?
20:21:31 <dgilmore> bconoboy: i already know :) ill just tell you
20:21:56 <pwhalen> sounds good, all agreed on shipping tomorrow?
20:21:59 <bconoboy> dgilmore: in that case I will tell you when it's safe to pull them from scotland :-)
20:22:00 <ctyler> +1
20:22:18 <jcapik1> +1
20:22:21 <bconoboy> +1
20:22:31 <dmarlin> +1
20:22:31 * ctyler wondering what our target for GA is (or should be)
20:22:41 <dgilmore> bconoboy: for GA we really need to have the VEXPRESS image using virtio :) packages are still installing
20:22:47 <bconoboy> ctyler: let's get through agenda and then talk about that
20:22:50 * dmarlin thinks that's for another meeting
20:23:11 <bconoboy> How many +1's do we need before we call it passed?
20:23:16 <pwhalen> #agreed final tests on images before F17 beta release tomorrow
20:23:19 <dgilmore> bconoboy: +1 its passed
20:23:23 <bconoboy> woot
20:23:34 <jcapik1> bconoboy: we need just positive sum i guess
20:23:45 <pwhalen> #topic 2) Release criteria for a F17 ARM final - Release criteria - http://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Final_Release_Criteria
20:24:53 <bconoboy> There are a lot of ARMTracker issues still open. Do we really need to close them all?
20:25:05 <dgilmore> bconoboy: we need to triage them all
20:25:14 <dgilmore> bconoboy: decide if they are blockers or not
20:25:21 <bconoboy> Okay, that's fine
20:25:23 <dgilmore> if they are blockers they need resolved
20:25:42 <dgilmore> bconoboy: we probably should have a ARMF17Blocker tracker
20:25:54 <dgilmore> and use that to track the blokcers that must be resolved
20:26:00 <ctyler> sounds reasonable
20:26:39 <bconoboy> I'd like to see specific hosts to be supported listed in the final release requirements.  If it's just vexpress and everything else is icing that's fine
20:27:28 <pwhalen> the panda and vexpress were the only targets we had
20:27:35 <ctyler> How bad/long does this Panda issue look?
20:27:36 * djdelorie would like minimum functionality on hardware, even if it means custom kernels.  X, usb, sound, etc, whatever's supportable
20:27:40 <bconoboy> do we want to stick with panda for final?
20:27:56 <jcapik1> ctyler: pretty bad ....
20:28:05 <bconoboy> ctyler: it's solvable, just not solved.
20:28:26 <jcapik1> bconoboy: we want :]
20:28:27 * dgilmore thinks we should support guru/sheevaplug, panda, beagle, trimslice, vexpress
20:28:46 <bconoboy> dgilmore: as release blockers?
20:29:30 * djdelorie thinks there's two support levels: targets with F17 official kernels, and targets with custom kernels
20:30:06 <dgilmore> djdelorie: custom kernels == on your own
20:30:07 <pwhalen> I think we should support them and release images but not block on them
20:30:26 <bconoboy> if we release we must support
20:30:35 <djdelorie> dgilmore: I mean, we provide a kernel-less image like we already do, or an image with a custom kernel
20:30:47 <bconoboy> nightly snapshots are at your peril, but this is different
20:31:18 <djdelorie> whether we *support* them or not is a different question
20:31:23 <bconoboy> dgilmore: Don't know about plugs (haven't created images for them), but your list is otherwise fine.  Which of those would we provide X support on?
20:31:27 <jonmasters> ctyler: it's likely trivially solvable, just needs some cycles. I've two other things to get to today, then I'll throw the rest of the day at it. If I can't fix Panda tonight, I'll at least send an email to make it upstream's problem with some analysis
20:31:29 <dgilmore> djdelorie: we shouldnt, people are free to take a image and replace the kernel
20:32:45 <ctyler> bconoboy: X-capable subset of that list is Panda, Trimslice, Beagle, vexpress. Do we have an open source fb implementation for each?
20:33:06 <bconoboy> ctyler: afaik, only vexpress works with X today.
20:33:08 <jcapik1> bconoboy: are you still trying to create a Panda/X image?
20:33:08 <djdelorie> I tested vexpress X last week
20:33:28 <djdelorie> iirc trimslice FB needs 3.5 or 3.6
20:33:28 <jonmasters> omap has omapdrm
20:33:29 <bconoboy> jcapik1: no, awaiting confirmation that it's useful to do so
20:33:36 <jcapik1> bconoboy: it is
20:33:43 <ctyler> I tested vexpress X too, worked fine
20:33:46 <jonmasters> but not sure of status of omapdrm actually working in f17
20:33:47 <bconoboy> our panda kernel has X support?
20:34:03 <dgilmore> tergadrm needs a bunch of stuff in linux-next
20:34:04 <jonmasters> that kernel has a staging driver for drm
20:34:06 <jcapik1> bconoboy: it currently works with ubuntu kernel only, but ...
20:34:13 <dgilmore> so likely will be able to be added in 3.5
20:34:23 <bconoboy> jcapik1: right, so, to add X support is just a yum install command
20:34:26 <jonmasters> bconoboy: we'll certainly have OMAP in F18, might be able to do an update in F17 for it
20:34:27 <jcapik1> bconoboy: I hope we'll get a working panda kernel soon
20:34:43 <dgilmore> jcapik1: using a ubuntu kernel is not a supported recommened whatever you want to call it option
20:34:50 <bconoboy> Okay, so the only X image for F17 Final, as a release blocker, is vexpress?
20:35:13 * djdelorie is OK with that
20:35:19 <jcapik1> dgilmore: we can at least prepare it
20:35:20 <jonmasters> I think so, and I wouldn't even make it a blocker, but I guess
20:35:25 <jcapik1> dgilmore: and test
20:35:35 <bconoboy> jonmasters: We need something to test X release criteria on.
20:35:43 <jonmasters> sure, ok, do vexpress then
20:35:58 <dgilmore> jcapik1: there is no point in testing using something we will never ship
20:36:23 <jcapik1> dgilmore: don't we wanna ship it?
20:36:38 * jonmasters has no interest in using an Ubuntu kernel for testing - we can build some hacked up kernel package for testing based on Fedora if we want to stash something on a fedorapeople page
20:36:40 <bconoboy> Okay.  So for F17 final we will support: Serial Console Panda, Beagle, Trimslice, VExpress.  For X we will support VExpress.  We can evaluate the dream/guruplug after this meeting and add it later if wanted.
20:37:04 <djdelorie> if we don't already have a plug image, let's skip it.
20:37:04 <jonmasters> bconoboy: sure
20:37:16 <jonmasters> +1
20:37:18 <pwhalen> bconoboy +1
20:37:23 <dmarlin> bconoboy: +1
20:37:27 <ctyler> +1
20:37:58 <ctyler> bconoboy: would be good to have a guru image, gives us a v5tel platform
20:38:05 <bconoboy> pwhalen: I think they like it :-) Anything else on release criteria?
20:38:13 <pwhalen> I can setup the ARMF17Blocker tracker mentioned earlier
20:38:18 <bconoboy> ctyler: I'm actually making a beagle armv5tel image for pbrobinson's benefit...
20:38:33 <dgilmore> jcapik1: we want to ship it, its enabled in our kernel, testing a ubuntu kernel is invalid as a test case, as they have who knows what patching in it. and it doesnt match what we ship, either way we can introduce/fix bugs by the differences
20:38:39 <bconoboy> ... plus the rpi images, but expect those to be deprecated soon
20:38:53 <dgilmore> bconoboy: i have a very happily working guruplug
20:38:55 <nb> rpi deprecated?
20:39:03 <dgilmore> bconoboy: need to update and test my sheevaplug
20:39:04 <ctyler> we can't ship the rpi images in Fedora, they have to be a remix
20:39:11 <nb> ctyler, oh
20:39:16 <bconoboy> nb: bconoboy-rpi images deprecated when seneca does an official release
20:39:32 <jcapik1> dgilmore: ok .... let's test it once we have our own kernel
20:39:48 <pwhalen> #agreed  F17 final we will support: Serial Console Panda, Beagle, Trimslice, VExpress.  For X we will support VExpress
20:39:50 <bconoboy> dgilmore: Let's discuss guru images after the meeting
20:40:00 <pwhalen> #topic 3) Upgrade Koji builders to F17? - Is there a reason to upgrade at this time?
20:40:15 <bconoboy> I'd like to, at a minimum, see F17 kernels on our arm builders.
20:40:22 <djdelorie> what's the ETA on dropping F15 support in koji-arm ?
20:40:24 <fossjon> when does primary arch update their builders?
20:40:27 <dgilmore> bconoboy: ok
20:40:39 <bconoboy> fossjon: primary uses RHEL kernels on their builders. We don't have that option
20:40:40 <nb> fossjon, primary arch uses rhel
20:40:41 <djdelorie> primary arch builders aren't Fedora anyway
20:40:47 <dgilmore> fossjon: primary builders run latest RHEL
20:40:48 <fossjon> hmm
20:40:52 <fossjon> i forgot that
20:40:54 <dmarlin> I'd like to wait at least until F17 is GA
20:40:54 <fossjon> ok nm
20:40:58 <ctyler> bconoboy: a large number of our builders here are Pandas, aren't we gated on getting that kernel?
20:40:59 <bconoboy> I don't feel good about using a 2.6.4x kernel with Fedora 17.
20:41:14 <jwb> bconoboy, why
20:41:18 <dgilmore> F15 will be EOL for primary 1 month after f17 GA
20:41:24 <bconoboy> ctyler: Yes, but I expect we'll resolve that soon enough
20:41:38 <dgilmore> so i feel that between GA and EOL we should migrate them
20:41:39 <djdelorie> since we skipped F16, does F15 stay on the "supported" list until F18?  F15 is the "previous" release in our case...
20:41:46 <dmarlin> dgilmore: +1
20:41:50 <dgilmore> we could start building builder images and doing some testing
20:41:54 <ctyler> Right, and we can test on a couple builders at that point, and roll out when we get a good result.
20:41:56 <bconoboy> jwb: Because there may be (undocumented) differences on how packages behave differently when the version string is 2.6.x vs 3.0
20:42:19 <jwb> i would have expected those to all get flushed out by now
20:42:26 <jcapik1> bconoboy: me neither :] it can possibly affect our tests
20:43:05 <bconoboy> In addition, the 3.3+ kernel may have capabilities that packages rely upon that we just don't know about, that are not present in 2.6.42 (3.2)
20:43:12 <ctyler> We have bcfg2 implemented across the buildsystem here (thanks Frojoe!) and we can use that to builderify a standard image once we get the kernels sorted.
20:43:19 <jcapik1> bconoboy: +1
20:43:28 * jonmasters advocates for keeping f15 alive until F18 beta
20:43:31 <jwb> f15 primary is on 2.6.43, which is 3.3
20:43:35 <bconoboy> jonmasters: Why?
20:43:38 <jonmasters> or alpha
20:43:41 <dgilmore> jonmasters: not viable
20:43:42 <ctyler> jonmasters: ???
20:43:46 <jwb> if you've been following that on arm properly, arm should be on 2.6.43
20:43:57 <jcapik1> jonmasters: +1
20:44:00 <bconoboy> jonmasters: I think you meant "f17 beta" :-)
20:44:02 <ctyler> jonmasters: define "alive"?
20:44:13 <djdelorie> we should at least keep F15's "yum update" working until F18, even if there are no new packages
20:44:14 <dgilmore> jwb: ive not built 2.6.43 for arm due to the issues we had with audit not working on 3.3
20:44:19 <jcapik1> we're missing f16 ....
20:44:21 <ctyler> We won't be getting fixes from upstream starting 5 weeks from now
20:44:21 <jonmasters> ctyler: available for downloading packages, etc.
20:44:23 <jwb> i see
20:44:29 <dgilmore> djdelorie: yum will always work for f15
20:44:34 <ctyler> jonmasters: available but not updated, sure
20:44:39 <djdelorie> until mirrors stop carrying it
20:44:39 <jonmasters> ctyler: yea
20:44:47 <bconoboy> I suggest, once F17 is *final* we start migrating builders to it.
20:45:01 <dgilmore> djdelorie: primary mirrors archive things, but never remove
20:45:09 <djdelorie> dgilmore: ha!
20:45:15 * jonmasters specifically made the F15 comment actually because I don't want to rush to touch the builders :)
20:45:16 <pwhalen> +1 bconoboy
20:45:19 <dmarlin> bconoboy: Ithink that's what dgilmore suggested, no?
20:45:21 <ctyler> bconoboy: s/migrating builders/testing a couple builders/
20:45:40 <bconoboy> ctyler: It can be a very conservative migration, over the course of months
20:45:40 <jonmasters> the builders are working (more or less). Testing a couple and doing a planned migration is ok, but very slowly
20:45:43 * djdelorie has an F15 arm server he'd rather not rush to update, too
20:45:44 <jonmasters> bconoboy: ok
20:46:19 * jonmasters is known to be very conservative about software updates :)
20:46:29 <jcapik1> it's good to have at least 2 (stable) releases
20:46:41 <dmarlin> bconoboy: are there other issues with a "mixed" environment (F15 & F17 builders) ?
20:46:54 <jonmasters> jcapik1: right, we won't get that, but we should keep f15 available somewhere for download, like the old mirrors on primary
20:47:05 <bconoboy> dmarlin: Only the kernel version is at issue- and I'd say it's more fragmented on our builders than it would be if we were on F17.
20:47:16 <dgilmore> jonmasters: just because its EOL doesnt mean its not available
20:47:20 <jonmasters> right
20:47:27 <dgilmore> jonmasters: just means that its not updated at all
20:47:30 <bconoboy> Switching builders is *different* From retiring F15 from repositories. Let's not combine the two.
20:47:31 <jonmasters> yea, indeed
20:47:35 <dgilmore> yum etc will still work
20:47:37 <dmarlin> bconoboy: I thought all the F15 builders were on the same kernel version
20:47:44 <dgilmore> and the bits will still be on the mirrors
20:47:49 <bconoboy> dmarlin: I don't think so
20:48:08 <dmarlin> bconoboy: please check
20:48:23 * jonmasters thinks the correct thing to do is to leave the builders alone for now. Once we have shipped F17, let's have a VFAD or two dedicated to making some very nice test images for builders and do some testing
20:48:31 <dmarlin> bconoboy: if not, I think they should be
20:48:33 <dgilmore> we really do want builders to all be identically configured
20:48:44 <dmarlin> dgilmore: +1
20:48:45 <jonmasters> then we can make some nice standard builder images
20:48:46 <djdelorie> that only works if they're identical hardware
20:48:52 <maxam> +1 jonmasters
20:49:00 <jonmasters> (reproducible)
20:49:02 <dgilmore> djdelorie: identical nvr wise
20:49:23 <jcapik1> jonmasters: +1
20:49:24 <pwhalen> +1 jonmasters
20:49:30 <jonmasters> the same scripts being used for the nightlies can be used to make some nice builder images
20:49:31 <dgilmore> we dont have the same hardware on primary.  but we do have the same nvrs and config files everywhere
20:49:48 <djdelorie> dgilmore: I was referring to just the kernel.  Let's nope the nvrs are the same otherwise
20:49:50 <fossjon> i dont get something
20:49:52 <jonmasters> then in another 6 months we can move to livemedia made builder images
20:49:58 <fossjon> if pa never updates their builders then why do we have to>?
20:50:09 <fossjon> or do they update their own rhel versions
20:50:17 <ctyler> bingo
20:50:19 <djdelorie> fossjon: because it's better for us :-)
20:50:20 <jwb> PA doesn't use fedora.  they do update their rhel instances
20:50:24 <jonmasters> fossjon: indeed, they run a supported RHEL version
20:50:29 <fossjon> i know they dont use fedora
20:50:33 <fossjon> but do they update?
20:50:36 <jonmasters> yea
20:50:36 <bconoboy> rhel and PA get *much* better testing than arm.  using f17 as builders is good testing.
20:50:37 <dgilmore> fossjon: we update the builders on primary once a month
20:50:38 <fossjon> and if so how often
20:50:48 <dgilmore> fossjon: and reboot when there is a kernel update
20:50:54 <fossjon> i see
20:50:58 <jonmasters> I think it makes sense to upgrade to F17 only because F15 is going to be EOL
20:51:12 <jonmasters> otherwise I would advocate for remaining on F15 indefinitely :)
20:51:14 <bconoboy> f15 is also the first version of the combined arm/armhfp... Package origins are *slightly* dicey.  Much better situation with F17
20:51:19 <jonmasters> (if it aint broke...)
20:51:28 <pwhalen> #agreed once f17 arm is final we hold a vfad to create builder images and discuss the upgrade further
20:51:35 <bconoboy> and if I'm not mistaken, we still have F15 builders crashing on a fairly regular basis.
20:51:40 <ctyler> jonmasters: it will be broke, kernel features at least
20:51:47 <jonmasters> yea
20:51:50 <bconoboy> Just because we've gotten accustomed to rebooting a few systems a day doesn't mean that we have achieved stability.
20:51:51 * djdelorie agrees F17 is "better" but still thinks two available versions is better than one ;-)
20:51:58 <bconoboy> And we're never going to track down stability issues in an F15 kernel.
20:52:12 <pwhalen> #topic 4) vexpress kernel - who will take the lead on this?
20:52:21 <ctyler> bconoboy: not sure if it's "F15 builders" or "alpha-level hardware builders" that are doin' the crashing
20:52:21 <jonmasters> djdelorie: well F15 is going to be EOL so the best we can do is what we said, keeping the old bits available for download
20:52:32 <djdelorie> yes, that's what I want
20:52:32 <bconoboy> Sonar_Gal, frankly, it *is* broken.  And moving to F17 is the best path to a fix.  It can be incremental, but we need to agree when to do this.
20:52:54 <dmarlin> bconoboy: we did... once F17 is GA
20:53:06 <bconoboy> did we?
20:53:12 <jonmasters> yup
20:53:20 <dmarlin> bconoboy: sure, see the topic has changed
20:53:25 <dmarlin> :)
20:53:32 <bconoboy> whew. okay.
20:53:47 <jonmasters> we agreed with the builders to do a VFAD after F17, get some nice builder images tested, then plan a migration
20:53:56 <bconoboy> okay, vexpress :-)
20:54:18 <jonmasters> at this point vexpress is not a kernel internals issue so I do not need to own it
20:54:30 <jonmasters> we have a workaround for F17 to keep MMCI as a module
20:54:39 <jonmasters> therefore I suggest dgilmore and pbrobinson continue to work that
20:54:48 <bconoboy> Somebody needs to make non-scratch vexpress builds in F17 and F18 that actually work.
20:54:57 <bconoboy> I think dgilmore has f17 in hand
20:55:09 <jonmasters> what we need is a rebuilt official F17 kernel with the vexpress (not versatile) config either with MMCI built in or with the dracut config
20:55:16 <dgilmore> bconoboy: i have the changes sitting in my git checkout will commit and build
20:55:25 <jonmasters> I personally favor building MMCI in but I am happy with the dracut hack if you guys insist
20:55:42 <bconoboy> dgilmore: Okay, if you're taking F17 *and* F18 please communicate that to pbrobinson.  Jon will be hands off as well, so it's all yorus.
20:55:46 <dgilmore> i will also update dracut with patches to pull in modules needed on various arm systems
20:56:10 <jonmasters> bconoboy: right, I isolated the original problems with vexpress. My work is done ;)
20:56:26 <bconoboy> dgilmore: Is this a before-beta-release item?
20:56:26 <jonmasters> ok
20:56:40 <dgilmore> bconoboy: will be done today
20:56:47 <bconoboy> okay
20:56:48 <dgilmore> but a kernel build takes a long time
20:57:10 <pwhalen> #agreed dgilmore, pbrobinson to take the lead on vexpress kernels for f17, f18
20:57:20 <pwhalen> #topic 5) Your topic here
20:57:36 <jonmasters> however, for testing and making images we do need to agree what is landing, etc. So there is a dracut update, ok. Then there's a kernel rebuild. If you want to wait for the kernel then can be hit the button on that now?
20:57:37 <pwhalen> anything else to be discussed in our final 3 minutes?
20:57:42 <djdelorie> do we have a guess for F17 final?
20:57:48 <jonmasters> We have the kernel config for vexpress, etc. Who's hitting the build button?
20:58:13 <bconoboy> topic 5: What's the deal with raspberry pi f17?
20:58:14 <dgilmore> jonmasters: i am
20:58:18 <ctyler> Actually, a Target would be better than a guess :-)
20:58:23 <jonmasters> ok
20:58:50 <djdelorie> bconoboy: mine is ETA end of June still
20:59:05 <bconoboy> er, I mean, the F17 release for the raspberry pi
20:59:09 <bconoboy> s/release/respin/
20:59:25 <ctyler> bconoboy: We're close to a beta. Need to beat the Debian frankenimage on a couple of performance issues :-)
20:59:56 <ctyler> I'm hoping to get the kernel/firmware combo nailed down tomorrow.
21:00:43 <dgilmore> ctyler: how goes the getting support upstream?
21:01:42 <ctyler> dgilmore: communication is still swamped out, it's like a CPU that's trashing. I got word from Eben on one issue out of 5 I asked him about :-S
21:02:27 <ctyler> I have commit on the github linux repo for the rpi, will push the fedora config. We really need to get it upstreamed from there or we'll be patching forever.
21:02:44 * ctyler meant, really need to get the rpi patches upstreamed to the kernel
21:03:33 <pwhalen> anything else we would like to discuss? its after 5 now..
21:03:45 <pwhalen> (no other meetings scheduled here)
21:03:57 * ctyler has some topics that can wait
21:04:15 <jcapik1> nothing else
21:04:21 <djdelorie> +1 on -1 meeting :-)
21:04:28 <bconoboy> +1
21:04:29 <pwhalen> .... last call!
21:04:41 <pwhalen> #endmeeting