| bpepple | topic FESCo meeting -- Init process | |
|---|---|---|
| --- bpepple has changed the topic to: FESCo meeting -- Init process | ||
| hughsie | can somebody please ping me when you need me, thanks. | |
| bpepple | FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, sharkcz, jds2001, j-rod | |
| Hi everybody; who's around? | ||
| hughsie: will do. | ||
| * nirik is heree. | ||
| sharkcz here | ||
| nirik | here even | |
| * dgilmore needs to leave in 20 minutes | ||
| deepthot | Dave W here for liblvm | |
| * j-rod here | ||
| * bpepple waits another couple of minutes before starting. | ||
| bpepple | alright, I see six FESCo members so we can probably get started. | |
| .fesco 64 | ||
| zodbot | bpepple: #64 (liblvm - https://fedoraproject.org/wiki/Features/liblvm) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/64 | |
| bpepple | deepthot: since your here we might as well start with your feature. | |
| deepthot | fine | |
| bpepple | anyone have any questions for deepthot | |
| +1 to liblvm feature. | ||
| notting | +1 | |
| sharkcz | +1 | |
| nirik | no real questions here... looks nice. +1 | |
| j-rod | +1, no questions here either | |
| bpepple | ok, I see five '+1', and no objections, so we've approved the liblvm feature. | |
| bpepple | if there are no questions, we can move on. | |
| bpepple | .fesco 28 | |
| zodbot | bpepple: #28 (Stronger Hashes) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/28 | |
| bpepple | mitr: ping. | |
| * mitr is here | ||
| bpepple | here's a link to the feature page: https://fedoraproject.org/wiki/Features/StrongerHashes | |
| bpepple | ok, so this feature won't allow upgrades from F9, correct? | |
| mitr | Last week we discussed the possibilities for making (yum upgrade) from F-9 work, and deferred to hear directly from Panu. | |
| mitr | Panu couldn't come tonight, here's his reply: | |
| | | Updating F9 rpm to 4.6.0 would be a completely irresponsible deed (just | |
| the kind of thing people are complaining on fedora-devel whenever the | ||
| "updates" subject comes up). It has a wildly incompatible API and various | ||
| other incompatibilities that will break existing setups. People can be | ||
| expected to deal with such things when upgrading to a new distribution | ||
| version but not in an update to what is supposed to be a stable release. | ||
| Backporting the series of ~30 patches that make up the strong hash support | ||
| mitr | to the very different codebase of 4.4.2.x is technically possible but | |
| painful work that touches a lot of deep internals and has some API/ABI | ||
| implications too IIRC. | ||
| Going through the very non-trivial amount of work that either of the above | ||
| requires and risking the (relative ;) stability of rpm of an released | ||
| distro version, for an unsupported upgrade path, is just madness IMO. If | ||
| mitr | FESCo *really* wants it, they need to find somebody else to maintain the | |
| mitr | F9 rpm. | |
| Putting the hashes aside for a moment... the Big Issue here is the | ||
| mitr | horrible burden that preupgrade "support" brings: if preupgrade is | |
| supposed to work across any Fedora N+2 version upgrade, it means that | ||
| *any* new rpm capabilities can only ever be deployed with a 1.5-2 year | ||
| delay (for some things backporting is feasible, for other things might be | ||
| mitr | impossible). That starts making even RHEL fast-moving in comparison. | |
| * nirik notes this isn't about preupgrade... it should work, right? it's yum updates? | ||
| mitr | Preupgrade works. | |
| nirik | because the f9 rpm can't grok the f11 rpms with 256hash to upgrade to them | |
| bpepple | mitr: what if we bump this feature to F12. We wouldn't run into this upgrade problem then. | |
| j-rod | bpepple: no, because f10's rpm groks 256-bit hashes | |
| bpepple | j-rod: ah, ok. | |
| j-rod | (iirc) | |
| mitr | bpepple: The other parts (repodata, RPM signatures), ... are independently useful. | |
| nirik | yeah, how about moving the rpm part to f12... | |
| but keeping the rest. | ||
| mitr | If the upgrade problem is a blocker, I'd propose moving only the filedigests part. | |
| notting | mitr: which bit specifically is incompatible? filedigests? gpg sigs? both? neither? | |
| mitr | notting: AFAIK filedigests only. (RHEL5 handles signatures, so F-9 should as well) | |
| j-rod | I'm still not entirely sure why we can't just make f9 users do a two-stage upgrade if they want to go from f9 to f11 :) | |
| * notting notes that we used to update the rpm library version in stable releases occasionally | ||
| j-rod | f9 -> f9 + f10's rpm -> f11 | |
| nirik | j-rod: we could. It's going to confuse/annoy/anger some people, but perhaps it's worth it. | |
| the failure I assume would be that f9 rpm won't do anything with the f11 packages right? it doesn't mess up and partly install them or something? | ||
| j-rod | simply having to upgrade at all to keep getting updates annoys some people, so meh | |
| mitr | nirik: the new rpms have a rpmlib() dependency, so the transaction aborts before touching the disk. | |
| nirik | mitr: excellent. | |
| * nirik is not really heavily leaning either way... a) deffer the filedigests only or b) just make people do f9->f10 if they are going that path... | ||
| notting | i would prefer a clean upgrade path for f9. but given that preupgrade will still work.... +1 | |
| nirik | mitr: how hard is it to just not do the filedigests by default? just a default? | |
| bpepple | +1, I'm not terrible thrilled about the upgrade path, but if we clearly explain the steps to handle it, I can live with it. | |
| mitr | nirik: What do you mean exactly? | |
| nirik: There's a rpm macro that determines at build time what hash will be used for filedigests. | ||
| notting | (back in 5) | |
| nirik | mitr: just wondering if it requires patches being backed out or anything... yeah, macro is what I was hoping/expecting. | |
| nirik | I guess +1, but we should update the yumupdatefaq page now with info about this. ;) | |
| sharkcz | +1 with a release note about the "2 step" for "yum update" and confirmation it really works | |
| mitr | sharkcz: I have tested it, it works. | |
| bpepple | ok, I see four '+1'. dgilmore, j-rod? | |
| sharkcz | mitr: thanks | |
| j-rod | sorry, wasn't quite clear what we were voting +1 for... | |
| 2-step upgrade from f9 -> f11 +1 | ||
| bpepple | j-rod: right. | |
| alright, that's five '+1', so we've approved the StrongerHashes feature. | ||
| mitr | Thanks :) | |
| bpepple | mitr: thanks for taking the time to answer our questions. | |
| bpepple | alright, moving on.... | |
| nirik | thanks mitr | |
| bpepple | .fesco 58 | |
| zodbot | bpepple: #58 (AutoFontsAndMimeInstaller - http://tinyurl.com/cqjvaa) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/58 | |
| bpepple | hughsie: ping. | |
| hughsie | bpepple: thanks | |
| j-rod | +1 | |
| slick stuff | ||
| bpepple | hughsie: are we going to time the rebuild with the gcc & architecture rebuild? | |
| sharkcz | hughsie: the codecs installer is tied to gstreamer? | |
| hughsie | bpepple: well, for the desktop file data it just works now, a global rebuild wil make that bit just work | |
| hughsie | sharkcz: yes, but it's prefixed with gstreamer0.10() | |
| dgilmore | -1 | |
| bpepple | hughsie: ok. | |
| hughsie | the font stuff is still being worked on by behdad | |
| bpepple | dgilmore: what's your concern? | |
| hughsie | it sort of works now, but behdad is making it rock harder | |
| sharkcz | hughsie: ok | |
| mclasen_ | hughsie: are you sure behdad is still working on it ? afaik, he's gone for the next week | |
| so better check with him | ||
| dgilmore | bpepple: that too many peopel will not do the 2 steps | |
| hughsie | mclasen_: i sent email this morning to you, behdad and nim-nim | |
| bpepple | dgilmore: oh, is this about the stronger hashes feature? | |
| hughsie | nim-nim: seems to think behdad is making this better | |
| dgilmore | bpepple: yeah sorry | |
| * dgilmore is distracted today. and needs to run in a couple of minutes | ||
| bpepple | dgilmore: np. I thought your vote was about the hughsie's feature. | |
| nirik | dgilmore: it's only yum updates, and it won't break them, just not allow them to update... | |
| notting | +1 on fonts&mime&stuff | |
| sharkcz | +1 | |
| nirik | hughsie: so what does the dialog look like if it can't find something? | |
| bpepple | +1 to fonts installer feature. | |
| hughsie | nirik: it says "can't find foo" and the more info button takes you to the fedora wiki page | |
| nirik | which wiki page? | |
| hughsie | i'll see if i can find a screenshot | |
| nirik | +1 in any case, just curious. | |
| hughsie | nirik: cat /etc/PackageKit/Vendor.conf | grep Url | |
| depends on the distro | ||
| (i've got an upstream link) | ||
| bpepple | ok, I see five '+1' to the font installer feature, so we've approved it. | |
| hughsie | somebody patched the F10 rpm | |
| hughsie | bpepple: great, thanks | |
| bpepple: that's the desktop file feature too, right? | ||
| hughsie | aka: https://fedoraproject.org/w/uploads/3/30/Gpk-client-mime-type.png | |
| nirik | https://fedoraproject.org/wiki/PackageKit_Items_Not_Found in the f10 version at least. | |
| bpepple | hughsie: correct. | |
| hughsie: thanks for taking the time to answer our questions. | ||
| hughsie | no problem at all | |
| bpepple | ok, if there are no other questions, we can move on. | |
| .fesco 59 | ||
| zodbot | bpepple: #59 (ControlGroupsKernel - https://fedoraproject.org/wiki/Features/ControlGroupsKernel) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/59 | |
| bpepple | didn't we push this so we could talk to the feature owner? | |
| nirik | yeah, I don't see anything on the talk page tho. | |
| j-rod | no, that was the tools portion | |
| sharkcz | bpepple: there is now kernel and tools part | |
| bpepple | since we sent out the schedule so late, most likely the owner wasn't aware it was on today's schedule. | |
| j-rod | there's also a ControlGroupTools | |
| er, ControlGroupsTools | ||
| bpepple | j-rod: ah, ok. | |
| nirik | why do we need seperate features ? shouldn't it just be one? ControlGroups? | |
| j-rod | was kinda wondering that myself | |
| sharkcz | different teams are working on those parts ... | |
| j-rod | and what exactly isn't done? says 75%, but also says everything listed there is already in F10 | |
| vwbusguy | http://www.seriouseats.com/2008/10/a-lampshade-made-out-of-bacon.html | |
| j-rod | er, not quite all | |
| nirik | how about we table again, ask them to try and merge into one feature and update status? | |
| j-rod | yeah, really feels like a single feature, not two separate ones | |
| nirik | even if it's seperate teams, they need to coordinate anyhow, why not just share a feature. ;) | |
| bpepple | I'm fine with seeing if the owners think it makes sense to combine them into a single feature page. | |
| j-rod | yep. and obviously, if we booted the kernel side as a feature, we couldn't realistically approve the tools side | |
| bpepple | so, any object to seeing if these two features can be merged into one? | |
| j-rod | nope, do it | |
| bpepple | done. moving on...... | |
| .fesco 62 | ||
| zodbot | bpepple: #62 (NouveauAsDefault - https://fedoraproject.org/wiki/Features/NouveauAsDefault) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/62 | |
| j-rod | +1 | |
| * j-rod has a gf6200 that doesn't work at ALL w/nv, works great w/nouveau --> approve feature | ||
| nirik | +1, we can always yank it if it's breaking too much... | |
| notting | 0 on the premise that i have a nvidia card that works fine with nv and dies horribly with nouveau :) | |
| hughsie | (as an aside, the nouveau guys are very quick at fixing up regressions) | |
| sharkcz | +1, I had gf6600 that worked with nouveau, but not with the blob :-) | |
| hughsie | (and if we want KMS, we can't do it with nv) | |
| nirik | if we are doing this, we should change it asap, so we can get them bugs to fix. ;) | |
| j-rod | kms and compiz and whatnot | |
| hughsie | j-rod: not compiz yet | |
| j-rod | no, not yet, but eventually | |
| mclasen_ | nirik: no point in switching before its good enough | |
| j-rod | i.e., never going to happen w/nv, actually has a chance w/nouveau | |
| mclasen_ | that just frustrates testers and generates needless bugs | |
| nirik | mclasen_: how do we know without switching? | |
| hughsie | mclasen_: my feeling is that we're getting 0.0001% of the new users switching to nouveau | |
| as it means creaitng a xorg.cong | ||
| mclasen_ | yeah, if we want it in f11, i certainly needs to be switched before beta | |
| hughsie | mclasen_: if we switch early then we can put instructions in the release docs about how to switch back to nv, and ask people to file bugs | |
| notting | so, this seems to be a change that would leave fedora (for better or worse) very much alone | |
| hughsie | notting: yes, but we have a nouveau developer working at red hat... | |
| j-rod | I'd wager most *buntu people using nvidia cards use the blob anyhow. :) | |
| hughsie | j-rod: and i would agree with you | |
| bpepple | j-rod: yeah, I would guess so also. | |
| hughsie | and then they fill up launchpad with random crashes | |
| j-rod | so someone send notting a nouveau developer to fix his card, then maybe we can get his +1 too... | |
| notting | j-rod: bug's been open nearly two years :/ | |
| bpepple | +1, but we need to really give this some serious QA since this has the potential to affect a lot of folks. | |
| j-rod | hrm. suck. | |
| notting | in any case, i see 4 '+1' and 1 '0'... other votes? | |
| sharkcz | probably not as dgilmore is away now | |
| j-rod | can't we also selectively punt just problematic classes of cards back to nv? | |
| notting | j-rod: that gets messy in the x server for the non-xorg.conf case | |
| j-rod | though I suppose its entirely possible cards w/the same device IDs go bonk due to vendor-specific implementation details | |
| bpepple | ok, I don't see a majority vote, so maybe we punt this to next week when we have more folks here. | |
| * nirik nods | ||
| j-rod | notting: isn't it all device id based? | |
| * mclasen_ will try to lure some x people here next week then | ||
| notting | well, i'll switch my vote to +1. but i'm nervous about it being good enough | |
| bpepple | notting: yeah, I'm nervous also. | |
| j-rod | likewise, but there's a solid contingency | |
| notting | j-rod: by way of a big nasty case statement, yes | |
| bpepple | but anyway with notting's vote that gives us five '+1', so the nouveau feature has been approved. | |
| j-rod | notting: ew. | |
| notting | (also nervous about the bus factor) | |
| j-rod | "bus factor" == pci-e vs. agp vs. pci or ______ ? | |
| notting | no. 'number of people that have to be hit by a bus to incapacitate the featre' | |
| j-rod | hahaha | |
| bpepple | ok, anything else about the nouveau feature? | |
| j-rod | just that we suggest this one needs to be tested HARD | |
| bpepple | j-rod: strongly agree. | |
| j-rod | test-me-harder | |
| bpepple | ok, moving on then, | |
| --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora | ||
| bpepple | I believe that was everything on today's schedule. | |
| anyone have anything else they want to talk about? | ||
| * bpepple gets ready to start the countdown clock if no one speaks up. | ||
| notting | f13: where do we stand on scheduling the rebuild? | |
| are all required rebuild-affecting features approved? | ||
| bpepple | notting: I believe all the features that needed a rebuild have been approved. | |
| nirik | did we want to look at the qa request? | |
| nirik | .fesco 47 | |
| zodbot | nirik: #47 (Documented QA Team Scope) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/47 | |
| bpepple | nirik: I don't think anyone from qa is around. | |
| nirik | ah, then not. ;) | |
| bpepple | looks like f13 isn't around. Are there any other questions? | |
| notting | well, does fesco have any objections to the mass rebuild starting next week, if releng wants to do so? | |
| * notting looks at the schedule for beta.... | ||
| bpepple | I've got no objections to giving releng the authority to starting rebuilds. | |
| * nirik doesn't. | ||
| f13 | that exiI'm around | |
| sorry | ||
| I was deep in wiki editing. | ||
| nirik | this is going to be 100% right? since we need the new rpm hashes even for noarch? | |
| f13 | notting: that's correct | |
| bpepple | nirik: I believe that is correct. | |
| f13 | this would be a 100% rebuild | |
| what I don't know yet is | ||
| A) are gcc folks ready for the rebuild | ||
| B) is rpm ready for the larger hashes | ||
| C) is rpm ready for the fonts provides | ||
| bpepple | hmm, a lot of ducks to get in order there. | |
| f13 | D) are there any other things that would benifit from the full rebuild that aren't in place yet? | |
| nirik | are we going to do any change to the /i386/ in the repo paths? or leave it... | |
| f13 | oh right | |
| E) archful builds, which may require koji changes | ||
| notting | nirik: leave it | |
| nirik | ok, fine by me... might confuse some people, but not a big deal. | |
| notting | nirik: after all, it's not like we really support i386 now | |
| mbonnet | f13: I don't think we have support for larger hashes in Koji yet | |
| nirik | true. | |
| f13 | mbonnet: koji needs changes for the larger rpm hashes? | |
| not the gpg key stuff yet, just the rpm hashes themselves? | ||
| mbonnet | f13: yes | |
| f13 | oh dear. | |
| what's the ETA on that? | ||
| mbonnet | f13: I believe it does, let me check | |
| j-rod | koji bits link against rpm libs... | |
| mbonnet | j-rod: yes, but we record the payload hash in the database | |
| and right now we're pulling out rpm.RPMTAG_SIGMD5 | ||
| j-rod | (half-question, half-statement there... :) | |
| mbonnet | I assume that'll change to RPMTAG_SIGSHA256 or something? | |
| f13 | mbonnet: good question for the rpm folks | |
| mbonnet: is the koji changes required tracked on the StrongerHashes feature page? | ||
| mbonnet | f13: not sure, there's a ticket about it in Koji trac | |
| f13: https://fedorahosted.org/koji/ticket/119 | ||
| notting | crap, i thought this was already handled | |
| mbonnet: what happens if the wrong hash is recorded? | ||
| j-rod | iirc, it wouldn't be the wrong hash, it'd be no hash | |
| mbonnet | notting: well, I'm going to assume that if we're using sha256, then either RPMTAG_SIGMD5 is no longer defined (AttributeError) or will return null (database error) and we'll be unable to import any new packages | |
| f13 | that would be bad. | |
| So it looks like we're held up on a new koji deployment, and then landing some of the above stuff. | ||
| and the clock is ticking, loudly | ||
| considering that a full rebuild is going to stuff the buildsystem up for probably a week | ||
| bpepple | f13: how much of a window do we have to get this stuff done. | |
| s/./?/ | ||
| mitr | mbonnet: The tag is still used, but the strings are larger. | |
| mbonnet | mitr: so SIGTAG_MD5 will now return sha256 hashes? | |
| mitr | mbonnet: https://fedoraproject.org/wiki/RPM_file_format_changes_to_support_SHA-256 | |
| f13 | bpepple: beta freeze is 3.5 weeks away | |
| mitr | I've heard on a conf call that the koji plan is to simply stop tracking the hashes - they are only ever used to display them in the web interface. | |
| f13 | feature freeze is 2.5 weeks away | |
| bpepple | hmm, that's going to be pretty tight. | |
| f13 | the rebuilds should be done by feature freeze, to give time to clean up bugs before beta freeze | |
| so rebuilds really need to start in the next 2 weeks | ||
| mitr | Removing the code that adds the hashes to the database "should be" a very small change. | |
| f13 | mitr: yeah, but there are a ton of other koji changes in flight right now | |
| dgilmore: when is the koji outage ? | ||
| bpepple | f13: I think dgilmore had to step away. | |
| mbonnet | mitr: we also check the payload hash when importing rpms | |
| mitr | mbonnet: Hash of all packaged files, or some hash from the signature header? | |
| mbonnet | mitr: we're not longer storing file hashes, but we still store SIGTAG_MD5 (which I thought was a hash of the payload, unaffected by signing) | |
| mitr | mbonnet: SIGTAG_MD5 doesn't change. | |
| f13 | while an interesting debate, koji /will/ need changes for teh larger gpg keys | |
| and we'll need that prior to beta | ||
| mbonnet | mitr: ok, maybe this isn't a problem then. Though I was also told that we need to fix the way we grab signatures. | |
| f13 | mbonnet: you need to fix the way you grab gpg signatures | |
| mitr | mbonnet: yes, before beta - not before mass rebuild. | |
| mbonnet | f13: I'll work with mikem to make sure these changes are in the next Koji release (Feb. 28) | |
| nirik | koji update/outage is planned for the 21st. | |
| mbonnet | oh, is it 21st | |
| ? | ||
| f13 | 21st or 28th? | |
| notting | or 14th? :) | |
| nirik | Feb 12 13:12:15 <dgilmore> it will happen on the 21st and last ~48 hours | |
| f13 | I think we'll need some koji changes, maybe just configuration, to handle the building of everything .i586 | |
| nirik | thats what I have in my logs from the infrastructure meeting the other day. | |
| mbonnet | f13: isn't that a redhat-rpm-config change? | |
| f13: I think we'll still have i386 as the arch for the tasks, they'll just produce i586 packages | ||
| f13 | mbonnet: ok, wasn't sure about that | |
| lots of things in the air, I don't have it all in my head :/ | ||
| bpepple | yeah, this rebuild is covering a lot of things. | |
| ok, so is there anything else to discuss in regard to the upcoming rebuild? | ||
| notting | so, if we are tied to the feb. 21st date, that means we have a week to get everything in order | |
| f13 | I'd say we'd start the builds on the 23rd | |
| give the koji guys a couple days to shake out the new release issues | ||
| (and I don't really want to work that weekend) | ||
| notting | f13: does this mean this discussion and the plan should be items 1 through 23 for the monday meeting? | |
| mbonnet | f13: when is the beta (larger sigs)? | |
| f13 | mbonnet: beta freeze is 3.5 weeks away | |
| March 10 | ||
| notting | f13: so, that gives us one week to get the mass rebuild done before feature freeze? | |
| f13 | yes | |
| and a week from feature freeze to fix bugs for beta freeze | ||
| bpepple | f13: is that realistic? | |
| f13 | unless we aren't dependant upon new koji for the mass rebuld | |
| if we don't need new koji, we can start the rebuilds even earlier, depending on the other requirements. | ||
| to recap, I need to know: | ||
| A) When GCC is ready | ||
| B) When rpm is ready | ||
| C) When/if Koji is ready | ||
| notting | A is done | |
| f13 | and then I will break the system to its knees with background builds | |
| notting: no, they wanted it to sit in rawhide for a while before they were ready for a mass rebuild. | ||
| notting | (modulo any bugs, but we'll never know that) | |
| f13 | (unless you just confirmed with jakub today) | |
| notting | no, i didn't | |
| mitr | B rpm is ready, the macro must be put in redhat-rpm-config (or elsewhere?) | |
| mbonnet | mitr: is B) for larger hashes or i586-everywhere? | |
| f13 | I guess B is for both | |
| notting | f13: hm, maybe table this for the releng meeting? | |
| mitr | Oh - larger hashes are ready. I don't know anything about i586 | |
| f13 | notting: isn't it FESCo who needs to coordinate all these features? | |
| mbonnet | f13: I think we need to verify the i586-everywhere config changes, maybe in a separate tag | |
| notting | f13: all three features have been approved | |
| f13 | ugh, fine I guess releng will have to pick up the ball | |
| notting | f13: if you like, i can keep swapping my fesco and releng hat back and forth during the meeting | |
| f13 | fine by me | |
| notting | realistically, it will be the same people talking either way :/ | |
| and monday gives us a chance to demand people show up :) | ||
| f13 | I'll send a mail out to fedora-devel-list about it today | |
| mentioning that it'll be discussed at the releng meeting | ||
| notting | f13: want me to follow up with explicit invites to various people? | |
| f13 | sure, why not | |
| notting | ok | |
| f13 | I think we've probably beaten this topic to death | |
| bpepple | f13: yeah. | |
| ok, anything else, or should we wrap up for the day? | ||
| bpepple | alright, than.... | |
| * bpepple will end the meeting in 60 | ||
| bpepple will end the meeting in 30 | ||
| bpepple will end the meeting in 15 | ||
| bpepple | -- MARK -- Meeting End | |
| Thanks, everyone! | ||
| f13 | shoot | |
| bpepple | f13: something else? | |
| f13 | I'm probably too late to mention that Automated QA stuff will be coming on line very shortly | |
| bpepple | f13: cool. | |
| nirik | oh, who was supposed to be doing the summary for this meeting? | |
| f13 | informative only | |
| bpepple | nirik: dgilmore, but I'll do it. | |
| nirik | bpepple: thanks. | |
| f13 | we're waiting on a PHX resource from infrastructure, but may start generating things on a test box elsewhere before that happens | |
| f13 | the Fedora QA meetings will have regular reports about the autoqa efforts, and https://fedoraproject.org/wiki/Automated_QA_Testing_Project | |
| bpepple | f13: cool. I'll put a note in my meeting summary. | |
| f13 | thanks | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!
