From Fedora Project Wiki

< QA‎ | Meetings


People present (lines said)

  • jlaska (140)
  • adamw (73)
  • wwoods (68)
  • Oxf13 (39)
  • poelcat (26)
  • Viking-Ice (21)
  • kparal (20)
  • spot (7)
  • tibbs (2)
  • zodbot (2)
  • jwb (2)
  • buggbot (1)
  • tk009 (1)
  • pjones (1)
  • jeff_hann (1)



Previous meeting follow-up

  • jlaska will propose Common_F12_Bugs after meeting for bug#530541

Added to the list with help from User:wwoods and User:adamw (See Common_F12_bugs#preupgrade-boot). Also reorganized How_to_use_PreUpgrade and we've had several additional contributions to the troubleshooting section from User:Toshio and User:Mccann.

  • preupgrade test updates

Per last weeks FESCO meeting on preupgrade, QA team took an action item to update the preupgrade test cases (QA:Testcase Preupgrade and QA:Testcase Preupgrade from older release). Fedora QA trac ticket#30 is tracking this update. User:rhe and User:Kparal have adding their thoughts to the issue.

  • jlaska to send request for retrospective feedback to fedora-test-list@

Unfortunately, no action this past week. Will prioritize for this week and discuss next week.

Security Test Plan

Spot posted some great points around non-root user security expectations in his blog last week (see This seems to me like an interesting project worth pursuing for Fedora 13.

The team discussed at length, highlights include:

  • Spot updated his blog with the latest feedback from his blog -- see
  • part#1 - Should involve defining a security policy ... instead of making one up
    • This policy may take into account a method for each spin SIG to add spin-specific security policy.
  • part#2 - The QA team can support a security policy by creating test documentation (plans/cases) and providing test results

AdamW agreed to take the first step by initiating discussion with fedora-devel-list and fedora-security-list to begin the process of reaching consensus on a security policy.

Enhancing Release Criteria

John Poelstra has been thinking about enhancements to the current Fedora release criteria and has organized his thoughts into several wiki pages, starting with Fedora_Release_Criteria. There aren't intentions that this list will be the end-all be-all of checklists for the list. I know we've all experienced some of the subjective nature of identifying blocker bugs and assessing release impact.

Please take a few moments to review the criteria, along with the following pages, and offer your suggestions/corrections.

Fedora 13 release criteria

General FAQ around escalating blocker bugs - Blocker_Bug_FAQ

User:poelstra joined the meeting and recommended reading the email announcement first. John also indicated he was hoping this would set a better stage for more info that might come from the target audience discussion. The plan was to host healthy discussion on the mailing list until FUDCon. Then, at FUDCon, hammer out the dents and formalize something we can use for Fedora 13. John asked the team if this was realistic. Adamw and jlaska felt it was.

Wwoods noted that the original release criteria was started by writing down whatever unwritten common-sense tests and policies we already had, and maybe a couple "it'd be nice if.." ones. John thanked Will for starting the release criteria process, as many of the points raised in the original page are included in the new release-specific pages.

AutoQA update

wwoods updates

autoqa-0.3 merged into the master branch (see;a=commit;h=a27a03f527a76af24bac46dd3872efc9fd4e3984). This branch adds:

  • a new autoqa python library
  • which includes, shared repoinfo code for the watcher scripts and utility functions/classes for tests
  • the new post-koji-build hook. Which is still fairly experimental, but we have it running a simple 'rpmlint' test on every new build that comes out of koji

Wwoods outlined several FUDCon plans, including:

  • An info session on current and future plans
  • A hackfest on a solid depcheck test
    • Work to solidify the post-koji-build hook
    • Think of some possible ways to make it easy for package maintainers to add post-build tests
    • Get rpmguard up and running

kparal asked how work was proceed with running autoqa locally (see ticket#52). Wwoods indicated that was a prerequisite for maintainers to be able to work on post-build tests

kparal updates

While waiting for wwoods' big merge (52 commits ahead), I was trying to improve wiki documentation. So I created a new AutoQA front page (see AutoQA), which should work as a guidepost - different kinds of user can choose interesting stuff for them and go to a link for details. The previous content was moved to "AutoQA architecture" page. there's the post: Kamil advised ... not to look at the front page much in detail, it's going to change soon. Jlaska proposed an improved version for review at User:Jlaska/Draft which may replace the current version soon.

Kamil's plan for this week includes working on integration of rpmguard into autoqa. Wwoods noted that they'd need to figure out what to do with the output of the test (mail it to package owners/autoqa-results?) and what to do when there's a change that should block the package. But that can wait until after the test is working.


Open discussion - <Your topic here>

FUDCon - Oxf13

Jkeating announced plans to host a talk around the future of Fedora development. This talk would include outlining No_Frozen_Rawhide_Proposal, AutoQA, auto-signing, new milestones, and how all these puzzle pieces are supposed to fit together.

Jwb asked if the discussion could be recorded for those who would not be in attendance.

Target audience for DVD.iso - Viking-Ice

In reference to the Fedora target audience discussion, Viking-Ice asked, Who's the dvd img target audience. sysadmins [ or ] end users?

Jlaska pointed to the install guide which states:

 If you have plenty of time, a fast Internet connection, and wish a broader choice of 
 software on the install media, download the full DVD version

Wwoods provided a link to the fedora-advisory-board discussion -

Discussion followed around whether DVD/CD optical media was still required. The recommendation was to take any updates or discussion on this topic to the fedora-advisory-board list.

Upcoming QA events

  • NA

Action items

  • adamw - initiate security policy discussion on fedora-{devel,security}-list
  • jlaska to send request for retrospective feedback to fedora-test-list@

IRC transcript

jlaska #startmeeting Fedora QA Meeting 16:00
zodbot Meeting started Mon Nov 23 16:00:42 2009 UTC. The chair is jlaska. Information about MeetBot at 16:00
zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00
adamw morning 16:00
jlaska #topic gathering critical mass 16:01
jlaska hmm, I forget which tag gives the meeting a specific title 16:01
jlaska #meetingtitle qa 16:01
* kparal is here 16:01
* tk009 is here 16:02
* jeff_hann here 16:02
jlaska adamw: kparal tk009 jeff_hann - welcome :) 16:02
* Viking-Ice pops up.. 16:02
* poelcat here 16:02
* wwoods aliiiiive 16:02
* Oxf13 16:02
Oxf13 lucky to be alive 16:03
* jlaska tips hat to Viking-Ice, poelcat, wwoods and Oxf13 16:03
jlaska okay, let's get started then 16:04
* jlaska walking through proposed agenda 16:04
jlaska #topic Previous meeting follow-up 16:04
jlaska * jlaska will propose Common_F12_Bugs after meeting for bug#530541 16:04
buggbot Bug medium, low, ---, skvidal, CLOSED ERRATA, Free space check on /boot not thorough enough 16:04
jlaska well, this is done ... thanks of course to adamw for his mastery of wiki documentation! 16:05
jlaska you can see what came out of this at ... 16:05
jlaska Common_F12_bugs#preupgrade-boot 16:05
jlaska and some re-organization done to ... 16:05
jlaska How_to_use_PreUpgrade 16:05
adamw np 16:05
jlaska so thanks adamw and wwoods for the guidance there :) 16:05
jlaska next up ... somewhat related ... 16:06
jlaska * preupgrade test updates 16:06
jlaska for those following along with the home game ... rhe is helping by updating the existing preupgrade test cases to ensure we're catching this behavior 16:06
jlaska For details, checkout the trac ticket ... 16:06
jlaska 16:06
wwoods oh, that's "updates to the preupgrade tests" not "updated preupgrade packages in updates-testing" 16:07
jlaska wwoods: yeah, you got it 16:07
jlaska Hurry has helped cleanup the existing cases ... and with some guidance from kparal, a new case should be coming to target the /boot behavior 16:07
jlaska that'll probably finish up in a week, but just wanted to let folks know where it was 16:08
jlaska next up ... 16:08
jlaska * jlaska to send request for retrospective feedback to fedora-test-list@ 16:08
jlaska as you can probably tell, I've not managed to task this last week 16:08
* jlaska wears the cone of shame 16:08
jlaska I'm hoping to get this out this week of course ... so we can start the F12 retrospective and F13 planning process 16:09
adamw bad jlaska 16:09
jlaska indeed! 16:09
jlaska okay, that's all I had in the minutes from last week 16:10
jlaska I know folks have been busy, are there any other items to follow-up on that I missed? 16:10
* poelcat was wondering about having a release wide retrospective at FUDCon 16:10
poelcat would that be appealing to people or would they rather use our time there on something else? 16:10
jlaska poelcat: ooh, not a bad idea 16:10
poelcat it's easy to say "let's do ____ at FUDCon" but the time always goes fast! 16:11
jlaska definitely 16:11
jlaska well, I'm not opposed to it ... I've not figured out a great plan for processing the retrospective feedback ... other than documenting it on the wiki, and asking folks to think about areas they'd like to tackle to address the pain points 16:12
jlaska so, I'm open to different approaches 16:12
jlaska we can bounce around ideas on that after the meeting if you like 16:13
poelcat okay 16:13
poelcat carry on :) 16:13
jlaska and if no one responds to he mail ... I guess that helps answer it :) 16:13
jlaska s/he/the/ 16:13
jlaska okay ... swim suits on please ... let's dive in ... 16:14
jlaska #topic Security test plan 16:14
Viking-Ice This is something that each spin SIG needs to decided and adjust to their target audience and or the purpose of the spin. 16:14
Viking-Ice You can not impose the same rules on Desktop vs workstation/server deployment. 16:14
Viking-Ice The recent pk-fiasco was blown out of proportion and is a typical example for an incompetent admin who used and deploy an image who's target audience was home desktop end user ( Which I believe all the live *DE spins are as in being the latest *DE technology preview for the home desktop end user ) in a multiuser corporate/enterprise environment. 16:14
poelcat jlaska: can you give a little background by what you mean on a security test plan? 16:15
adamw Viking-Ice: PackageKit is on every default Fedora installation. 16:15
Viking-Ice I have no clue to who releng target audience is with the dvd img but i'm pretty sure that's not workstation/server deployment. if it is it should follow what's documented/recommended on CSI ( ). 16:15
jlaska poelcat: sure 16:15
adamw Viking-Ice: and that's not on-topic for us anyway. 16:15
jlaska so ... not really interested in churning up the waters on this front 16:15
wwoods no, I think it's on-topic to a certain extent; 16:15
jlaska it's been done plenty already and it seems the issues is being worked 16:15
jlaska what I wanted thoughts on from the group was something spot blogged about 16:15
wwoods the proposed security test plan includes a bunch of test cases tailor-made for a corporate workstation/server deployment 16:15
wwoods which is inappropriate for the board-defined use cases for the default spin 16:16
wwoods and for most of our other desktop spins 16:16
wwoods I think we can agree that the plan - as with all test plans - needs to be tailored to the needs of the spin 16:16
adamw where is 'the proposed security test plan'? 16:16
wwoods I think it also points out the need for a Server/Workstation spin. 16:16
jlaska 16:16
jlaska adamw: 2 parts to this ... what spot posted is certainly not the final product 16:16
jlaska Viking-Ice: and wwoods correctly note that there may be SIG specific test cases/areas for the tplan 16:17
adamw all of that seems perfectly sensible for _any_ multi-user setup. nothing corporate. 16:17
adamw if i were running a family PC that's pretty much what I'd want. 16:17
* spot notes that there are additional revisions to that which need to be made 16:17
jlaska I think we can certainly build into the plan a way to call out SIG specific tests 16:17
jlaska spot: yeah, I was reading the comments and going to ask where your "master copy" was 16:17
poelcat jlaska: so prior to final, QA would go through the list and verify each of them? 16:18
jlaska poelcat: so that's the thinking ... 16:18
spot jlaska: i was updating the post as the master copy initially, but i got busy and couldn't keep up 16:18
jlaska first ... someone would propose a test plan that touches on the content spot highlights 16:18
spot jlaska: i'll update it now 16:18
* adamw notes that most of those complaining about the PK issue were not corporate users, they were people with _home_ multi-user systems 16:19
jlaska once we have content we are all reasonably comfortable with and is something the team can manage ... I'd look to get this on the schedule for testing somehow 16:19
wwoods re-reading the list of stuff spot's got.. I think I agree with adamw, those items - and that definition of "unprivileged" - are very reasonable 16:19
adamw well, apart from the ones who were just complaining because they had nothing better to do. 16:19
wwoods and there are certainly things in the comments that people who want spins with stronger default policies might like to write test cases for 16:19
adamw but yeah, i find spot's list very reasonable and simple and a great place to start. 16:19
jlaska anyone interested in taking a stab at some initial content here? 16:19
adamw i'm not sure we want to move too fast 16:20
adamw logically we should start designing test plans once the parameters are actually set 16:20
jlaska adamw: what would you envision as the next steps? 16:20
wwoods and much respect to spot for harnessing an angry mob to create something useful 16:20
adamw we can't really draw up a test plan to check a security policy until there's a security policy 16:20
adamw right now there's a blog post with bullet points 16:20
adamw there's rather a gap from one to t'other :) 16:20
jlaska adamw: yes, fair point 16:21
Viking-Ice which leaves what base sec policy for desktop and another for workstation/server ? 16:21
adamw i know everyone's all crazy enthusiastic about this right now (heh)...but there's six months to the next release 16:21
jlaska adamw: I'd like to capitalize on spot's work here ... so the end result I'm hoping we can get to is a documented repeatable series of steps anyone can pitch in on 16:21
wwoods adamw: uh, yes, but there's 8 weeks to F13 feature freeze 16:21
poelcat lol 16:22
* poelcat was waiting for that 16:22
jlaska :) 16:22
adamw wwoods: please put that statistic down and back away slowly ;) 16:22
wwoods hey, this dead horse ain't gonna beat itself 16:22
adamw there's several squishy areas here that worry me that we're not going to address ourselves 16:22
jlaska adamw: cool, let's call those out 16:23
adamw basically what qa's going to need to have is a set of test cases to test each item of the security policy which make up a 'security test plan' 16:23
adamw but the thing is - what exactly would we be testing? 16:23
adamw there's however-many-zillion apps in the repos 16:23
adamw and we can't be absolutely sure which of them potentially allow any of these things to happen 16:23
adamw well, we probably can, but it requires someone to do some spade work 16:23
Oxf13 right 16:23
jlaska which is why I raise it here 16:23
wwoods I assume the policy would define some stuff - like a list of actions that unprivileged users must not be able to accomplish without an admin password 16:24
adamw is anyone on development side planning to do an audit to produce a comprehensive list of apps that use elevated privileges? is there going to be a policy for flagging up apps which do so in future? 16:24
jlaska first, wanted to get some scope for this issue ... so this is helping 16:24
wwoods the policy needs to outline *specific, testable* items 16:24
Oxf13 basically you're going to have to learn what mechanisms are used to elevate privs, such as PolicyKit, and then monitor packages that include policy files 16:24
jlaska adamw: I wouldn't be opposed to that ... but I'm not looking for version 1.0 to be the worlds most exhaustive comprehensive plan 16:24
pjones Oxf13: learning? but I hate learning! 16:24
jlaska I'm looking for _something_ to start with and build on for each future release 16:24
Viking-Ice is it not up to Fedora security to come up with the base security policy for desktop and workstation/server which we can then adjust create test plans for to make sure spins that fall under either category follow ? 16:25
adamw wwoods: but unless we have some mechanism to produce a reliable list of the apps that can touch items of security policy in any way, we have to test everything in the distro for each security policy provision 16:25
wwoods Viking-Ice: yeah, good point, but we can probably give guidance 16:25
Oxf13 Viking-Ice: that's a nice way of passing the buck. 16:25
adamw or make a list ourselves, which doesn't seem a) like our responsibility and b) like something we'd do very well 16:25
Oxf13 there's absolutely room for cooperation 16:25
wwoods adamw: ah, but we do - there are only a few ways to elevate privileges 16:25
Viking-Ice we can not blindly create test cases based on what ever we think mean that crew is the expert after all.. 16:25
adamw no, i think viking is right. our job is to test the policy, not to define it. 16:25
wwoods and this is an area we can probably request help on 16:25
adamw wwoods: that's exactly what i'm saying :) 16:26
jlaska #info part#1 of this effort should involve defining a policy 16:26
spot jlaska: updated 16:26
wwoods ah, I understand - we can't do it, so we should be *requesting help* outlining that stuff 16:26
adamw so i think we need a couple of things before we can sensible do any security policy testing: a security policy, and one that has a provision for treating security-sensitive apps sensitively. 16:27
jlaska #info the QA team can support the policy by creating test documentation (plans/cases) and providing test results 16:27
wwoods (for values of "can't" equal to "can, but don't necessarily have expertise and will need help and guidance &c") 16:27
adamw then we would have a reasonable degree of confidence in what it is we're supposed to be testing, and the set of packages across which we need to test it. 16:27
jlaska adamw: seems like a sensible approach 16:27
jlaska spot: thank you 16:28
adamw (i don't know about you but i don't want to spend the rest of my life checking if supertuxkart can change the system clock :>) 16:28
jlaska at this point, I just care about critpath 16:28
adamw that doesn't make sense, though 16:28
jlaska we can embrace extend as needed ... or ensure that the process supports that 16:28
adamw _any_ app that can screw over your security model is 'critpath' 16:28
Oxf13 erm. 16:28
adamw the critpath concept is only valid for application _brokenness_, not security 16:29
Oxf13 if supertux doesn't include a PolicyKit policy file, a link to consolehelper, or a suid binary, we don't care about it 16:29
Oxf13 we can easily narrow down the set of packages we do care about 16:29
adamw Oxf13: right. which is why i want an Official List of applications which can do privilege escalation, and some kind of policy for what we do with new ones 16:29
wwoods yeah, what Oxf13 said - it's *very* easy to detect the things needed to *attempt* elevated privilege 16:29
spot or, alternately, the testing can check a package for the prerequisites and if found, test 16:29
Oxf13 adamw: that's reasonable, but I'd do s/applications/methods/ 16:30
jlaska spot: yeah that's fair too 16:30
poelcat who can create an initial list of packages? 16:30
wwoods and, yeah, rpmguard should throw hell of red flags for anything with new security policy / suid binaries 16:30
spot as it is possible for a package to grow suid/consolehelper/policykit with an update 16:30
Oxf13 adamw: since suid is a method, not a package. 16:30
adamw true. 16:30
Oxf13 spot: right, this absolutely falls under post-build checking 16:31
adamw there's a wrinkle there, which is - how do we know what packages call an suid binary from a different package? 16:31
Oxf13 and red flag throwing. 16:31
kparal in rpmguard the suid check is already. we can add policy files check 16:31
jlaska okay ... so ... next steps here? 16:31
jlaska (rather ... first steps) 16:31
adamw i'd like to know what's going on already 16:31
Oxf13 adamw: that's not much of a concern, since the user could call the suid binary 16:31
adamw it seems like others may know more than me 16:31
adamw Oxf13: good point 16:31
Viking-Ice Is it not best to wait for what the security teams comes up with then adjust create/come up with and adjust test cases accordingly dont see much point in discussing the "how" until then.. 16:31
tibbs Forgive the interruption, but please note that I've tried for the better part of a year to get some security review of a package with suid binaries I was reviewing. I could never get any response. 16:31
adamw is there some kind of official effort to develop a security policy? is spot running it? 16:32
Oxf13 jlaska: step 1 should be getting help to define the set of methods which priv escalation can happen 16:32
jlaska adamw: what's going on already? can you be more specific? 16:32
wwoods tibbs: well that sucks. who've you been asking? 16:32
adamw jlaska: see above 16:32
jlaska adamw: ah gotcha ... 16:32
* spot is not running any sort of official effort at this time 16:32
Oxf13 tibbs: yeah, full fledged security audits aren't cheap, and likely won't be done in Fedora land :/ 16:32
tibbs fedora-devel and fedora-security-list. 16:32
Oxf13 I think all QA can reasonably do is identify the software that requires such an audit, and catch changes. 16:33
jlaska possibly 16:33
wwoods Oxf13: a semantic nit but that seems like it'd be part of the preamble to security policy - "this policy applies to any package which can elevate privileges. These packages can be found by ..." 16:33
adamw i think the first step is simple then - determine if we're actually planning to _have_ a security policy 16:33
Viking-Ice and what security bases should QA follow when doing such an audit? 16:33
jlaska okay ... so, this is certainly something people have a lot of thoughts on, which is great 16:34
adamw perhaps encourage it by pointing out that we can't do any meaningful security testing without one 16:34
Oxf13 wwoods: ok, not sure how that contradicts anything I've said 16:34
wwoods it doesn't, just trying to, uh, simplify the plan? 16:34
adamw if we assume that a security policy is actually going to emerge at some point, the second step is the policy/process for security-sensitive-packages 16:34
adamw after that, we can come up with test cases. 16:34
jlaska okay ... let's start to wrap-up this topic 16:35
Oxf13 Viking-Ice: honestly I think step1 is just identify the software which can elevate privileges. Auditing to come later by those who know how to audit. 16:35
adamw (all imo of course) 16:35
adamw i'd propose an official-from-the-qa-team mail to -devel-list summarizing this discussion 16:35
Oxf13 jlaska: proposal: Work with various teams to identify the methods in which software can elevate privileges. 16:35
Oxf13 jlaska: (continued): step 2 would be to work on tests to discover these methods used by packages, in order to identify software that needs auditing. 16:36
adamw i.e. pointing out the importance of having a security policy, and the parallel necessity for a list/policy for security-sensitive packages, and go from there 16:36
Oxf13 jlaska: so that when the security policy lands, we'll be ready with discoverability 16:36
Viking-Ice adamw: both the -devel and security list 16:37
jlaska is anyone in the meeting interested in representing QA to bring this discussion to -devel-list and -security-list ? 16:37
adamw i would if you like 16:38
adamw together with oxf13 representing releng i guess? 16:38
Oxf13 I"m sure I'll participate 16:38
Oxf13 I'm not signing up to lead anything else right now though (: 16:38
* adamw is not your guy for writing any actual tools to discover security-critical packages etc 16:39
jlaska now if this turns out to be a 5000 more involved than lets create a set of steps we can document and repeatably/reliably execute ... we can reconsider 16:39
jlaska adamw: I don't want any tools at this point 16:39
adamw but definitely your guy for over-long hectoring email discussions =) 16:39
Oxf13 I think right now we need to focus on discovery 16:39
wwoods I'll happily help with code to detect privlege escalation in packages 16:40
Oxf13 that will lead to more data about what kind of tools we need 16:40
jlaska alrighty, adamw if you'd like to start by putting some feelers out here ... that would be delicious 16:40
adamw Oxf13: i agree that's a basic pre-requisite, along with the commitment to develop some kind of sensible policy 16:40
wwoods I know kparal will want to put that in rpmguard 16:40
adamw Oxf13: if there's not going to be a policy it's kind of wasted effort 16:40
wwoods but I dunno if we're at that point yet 16:40
adamw but let's leap that hurdle when we get to it. 16:40
Oxf13 adamw: yeah, policy is important, but we can get from discovery to tools for discovering sensitive packages, long before we have a policy about what to /do/ with them. 16:40
jlaska adamw: you want to tackle this week, or shall I leave it on for next week? 16:40
adamw Oxf13: sure, it's just the commitment to there _being_ a policy that i'd like to see first, not the actual policy 16:41
adamw jlaska: i can send something out this week for sure 16:41
* jlaska notes it may be a short week for US folks 16:41
adamw is anyone here subscribed to -security-list already? 16:41
adamw i'm not, just want to know if there's been any discussion on this already 16:41
jlaska #action adamw to initiate discussion w/ -devel-list and -security-list on creating a security policy that QA can plan around 16:41
jlaska adamw: I'm not ... will subscribe now 16:41
jlaska so ... let's at least see where this project would take us 16:42
adamw i think with a clear policy and a list of sensitive packages it'd be relatively simply 16:42
adamw simple* 16:42
adamw 'check and make sure nothing from List A does any of the stuff in List B' 16:42
jlaska requirements sure make writing tests easier! 16:42
adamw which is good. i like simple. 16:43
jlaska okay ... let's move on to the next topic 16:43
jlaska thanks for the discussion/clarification on the security approach 16:43
jlaska #topic Enhancing Release Criteria 16:43
jlaska for this topic, I don't really want to discuss the details of the proposed criteria on IRC 16:43
jlaska more just to recognize that a proposal is out there ... and perhaps some points that will be good for QA to help further define 16:44
jlaska poelcat: were there any points I missed that you'd like feedback on? 16:44
jlaska for the logs ... 16:45
jlaska #info announcement - 16:45
poelcat i think its all in the email 16:45
adamw this is going to be pretty key to future releases so poelcat would love feedback 16:46
poelcat also trying to set a better stage for more info that might come from the target audience discussion 16:46
poelcat my hope was to have discussion on the mailing list 16:47
poelcat until fudcon 16:47
poelcat and then at fudcon hammer out the dents and formalize something we can use for Fedora 13 16:47
poelcat is that realisitc? 16:47
jlaska I would think so ... but I guess it depends on the feedback that comes in 16:48
adamw sounds good to me 16:48
Viking-Ice This proposal sounds sane to me so I got nothing to suggest for improvement or add to the current :| 16:48
wwoods For the record, I'd like to say that the Release Criteria were originally created just by writing down whatever unwritten common-sense tests and policies we already had, and maybe a couple "it'd be nice if.." ones 16:48
jlaska sounds like the security policy! :) 16:49
wwoods none of it was cast in stone and I'm really happy to see that it's finally getting some proper thought behind it 16:49
jlaska wwoods: actually, I think what was there is the basis/foundation for what poelcat has created 16:49
wwoods so thanks, poelcat 16:49
poelcat wwoods: you're welcome 16:50
poelcat you gave us a good start ;) 16:50
poelcat :) 16:50
jlaska wwoods: if there are any specific criteria from the previous page that you felt "I wish I we'd change it to ...", that'd be good feedback to have 16:50
poelcat the ";)" was accidental 16:50
poelcat that's all i've got 16:51
wwoods yeah I don't have any specific suggestions - and I'm happy that the awkward MUST/SHOULD convention was dropped 16:51
wwoods heh 16:51
jlaska alright cool, so please take a moment to review poelcat's mail 16:51
adamw yeah, that confused a lot of people. 16:51
jlaska if you hate it ... feel free to reply to the list 16:51
jlaska and of course, if you like it ... please do the same :) 16:51
Viking-Ice Well if you hate it reply to the list with what you think might be better... 16:52
jlaska Viking-Ice: right on! 16:52
jlaska Okay, let's change gears to our regularly scheduled AutoQA update ... 16:52
jlaska #topic AutoQA Update 16:52
jlaska wwoods: kparal: who wants to go first? 16:53
kparal wwoods is the one with the big changes 16:53
wwoods heh 16:53
kparal go on 16:53
wwoods okay, so: I merged the autoqa git branch I'd been working on 16:53
wwoods this branch brings in the new autoqa python library 16:54
wwoods which has shared repoinfo code for the watcher scripts and utility functions/classes for tests 16:54
wwoods and the new post-koji-build hook 16:54
wwoods which is still fairly experimental, but we have it running a simple 'rpmlint' test on every new build that comes out of koji 16:55
wwoods (I'd give a link here, but we don't yet have a public autotest instance, alas) 16:55
wwoods AFAICT it's still working, though - it's run 275 tests since I turned on the cron job on.. thursday? 16:55
jlaska wwoods: they seem to be still processing, sweet 16:56
wwoods (note to anyone who reads the git logs: I keep writing 'rpmdiff' when I mean 'rpmlint', please ignore that) 16:56
wwoods so that basically closes out the goals we had for the autotest 0.3 milestone 16:56
wwoods errr, sorry: *autoqa* 0.3 16:56
* adamw hands wwoods a coffee 16:57
jlaska heh, too many auto's :) 16:57
kparal too many similar names :) 16:57
wwoods there's a couple things we're planning to work on at FUDCon - primarily a hackfest on a solid depcheck test 16:57
wwoods to keep us from ever having broken deps in the repos 16:58
wwoods that will require a new post-bodhi-update hook 16:58
wwoods so - yes, those things are on the roadmap, but first we're prepping stuff for FUDCon 16:58
wwoods I think primarily we want to try to solidify the post-koji-build hook, 16:58
wwoods think of some possible ways to make it easy for package maintainers to add post-build tests, 16:59
wwoods and get rpmguard up and running 16:59
* jlaska wonders if kparal can remotely participate in the hackfest 16:59
jlaska the TZ's might not cooperate though 17:00
wwoods I'd hope so, but.. yeah 17:00
kparal I have to look at it 17:00
jlaska perhaps a morning session 17:00
kparal how about the local testing feature, wwoods? 17:01
wwoods oh! yes! 17:01
wwoods yeah - that's required for maintainers to be able to work on post-build tests 17:01
wwoods do we have a trac ticket for that? I forget 17:01
kparal I believe we have several, and a mailing-list thread :) 17:02
jlaska I can't find the specific ticket for that right now, but it might be hiding 17:02
kparal maybe this one: 17:02
jlaska aha ... it's not yet bound to a milestone 17:03
wwoods ah that's why I keep missing it. 17:03
jlaska kparal: but that's the one 17:03
wwoods we might think about a FUDCon milestone for stuff we need before that 17:03
kparal ok, let's attach it to the milestone then 17:03
jlaska either stuff to do before FUDCon ... or maybe things we can get help with @ FUDCon? 17:04
jlaska wwoods: lots of updates ... anything else on your radar or at risk? 17:05
wwoods jlaska: nothing springs to mind 17:06
jlaska kparal: how about with you? 17:07
kparal alright, when I was waiting for wwoods' big merge (52 commits ahead), I was trying to improve wiki documentation. So I created a new AutoQA front page, which should work as a guidepost - different kinds of user can choose interesting stuff for them and go to a link for details. 17:07
kparal The previous content was moved to "AutoQA architecture" page. there's the post: 17:07
kparal but don't look at the front page much in detail, it's going to change soon. after my changes jlaska worked on an improved version: User:Jlaska/Draft so it's possible it will replace the current version soon 17:08
kparal this week I plan to work on integration of rpmguard into autoqa, now when finally everything seems to be ready 17:08
kparal that would be it I guess 17:09
jlaska cool, I'm excited to see rpmguard in action 17:10
kparal I hope we are going to see some :) 17:10
jlaska wwoods: kparal: thanks for the updates 17:11
wwoods we'll need to figure out what to do with the output (mail it to package owners/autoqa-results?) and what to do when there's a change that should block the package 17:11
wwoods but that can wait until after the test is working 17:11
jlaska okay ... let's move to open discussion 17:11
jlaska #topic Open discussion - <your topic here> 17:12
Oxf13 FUDCON! 17:12
jlaska anything not covered in the meeting today that someone would like to discuss? 17:12
Viking-Ice Does any one know what the targeted audience is with the dvd img and is? 17:12
Oxf13 I think we need to get qa/releng up on the stage and walk people through the future of Fedora development 17:12
Viking-Ice that documented somewhere? 17:12
jlaska #topic Open discussion - FUDCon 17:13
Oxf13 Outlining no frozen rawhide, autoqa, autosigning, new milestones, how all these puzzle pieces are supposed to fit together 17:13
Oxf13 maybe even throw in the future SCM and message bus for flavor 17:13
wwoods mmm, futureflavor 17:13
jlaska Viking-Ice: I'll jump to your topic next ... 17:13
adamw will there be jetpacks? 17:13
adamw oh, please let there be jetpacks 17:13
jwb Oxf13, is that going to be recorded at all? 17:14
Oxf13 jwb: hopefully we can get this one recorded 17:14
jwb would be nice. i'd like to review since i won't be there 17:14
Oxf13 I'll take the lead on this 17:14
jlaska #info Oxf13 proposed a FUDCon discussion on the future of FEdora development process including NFR, AutoQA, autosigning, milestones and jet packs 17:15
adamw yaaaay 17:15
jlaska #topic Open discussion - dvd img target audience 17:15
kparal what exactly is the question? 17:16
Viking-Ice Who's the dvd img target audience 17:16
Viking-Ice sysadmins end users ? 17:16
jlaska according to the install guide ... 17:16
jlaska "If you have plenty of time, a fast Internet connection, and wish a broader choice of software on the install media, download the full DVD version" 17:16
wwoods so where's the link to that fedora-advisory-board discussion 17:17
kparal well if I have slow internet or no internet, I would burn Fedora DVD at my friends/buy it and I would have much more programs available 17:17
jlaska wwoods: the target audience discussion? 17:18
wwoods ah: 17:18
kparal they are not mentioning DVD there, just generally 17:18
Oxf13 at this point, the DVD has multiple target audiences 17:18
wwoods so there's that, but yeah, that doesn't specifically talk about the DVD 17:18
wwoods yeah. the DVD is problematic. 17:19
Oxf13 gnome desktop users, KDE desktop users, developers, and server admins 17:19
jlaska Viking-Ice: where were you thinking of going with this? Or what were you wanting to hilight? 17:19
adamw i don't think we have a story for the default dvd install 17:19
Oxf13 default DVD install is fairly similiar to the Desktop live image 17:20
wwoods the stories for the various spins / Live images is easier, since they're (theoretically) targeted 17:20
Viking-Ice More or less to establish if would be the recommended img for workstation/server install and the default pkg install set is targeted that way.. 17:20
Viking-Ice but not to the home end user.. 17:20
* poelcat wonders if we could eliminate the DVD and CD and just have the LiveCD 17:20
wwoods the default pkg install set for the DVD is roughly the same as the Desktop LiveCD 17:20
poelcat just brainstorming... no idea what the consequences would be 17:21
* Viking-Ice wonders if we cant eliminate optical media support altogether... 17:21
wwoods definitely can't eliminate optical media. not yet, anyway. 17:22
kparal well I know some people that are really burning linux dvds just because they want to use linux offline 17:22
Oxf13 poelcat: probably not until we solve upgrade from Live images 17:22
jlaska this is an interesting discussion, but is this in the right venue? 17:22
Viking-Ice usb key's ftw. 17:22
Oxf13 yeah, I really don't think this is QAs problem 17:22
poelcat Oxf13: it could reduce their problems :) 17:22
jlaska where is the appropriate place to raise concerns here? 17:22
jlaska I think this goes back to what adamw has said ... that we'd fully benefit from added clarity here 17:23
Oxf13 well, Fedora Board has been beating the target audience drum, so probably there 17:23
poelcat jlaska: post to f-a-b 17:23
jlaska poelcat: Oxf13: gotcha 17:23
jlaska Viking-Ice: I guess there we have it 17:24
jlaska okay ... if no other topics, let's call it a meeting 17:25
jlaska #topic Open discussion 17:25
* jlaska sets the timer @ 60 seconds 17:25
jlaska okay folks ... thanks for your time 17:26
jlaska #endmeeting 17:26

Generated by 2.7 by Marius Gedminas - find it at!