QA/Meetings/20090506

From FedoraProject

< QA | Meetings
Revision as of 19:03, 6 May 2009 by Jlaska (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

Attendees

  • adamw
  • wwoods
  • jlaska
  • Pip
  • viking_ice
  • f13

Previous meeting follow-up

  • [wwoods] - checking for a bug about an upgrade issue
    • Performing a lot of upgrade tests and working w/ dwalsh to identify+resolve issues
    • 494995 Aborting upgrade of F10 to F11-beta leaves system unbootable
    • 496618 bootloader.images.getDefault() returns None
    • 499321 preupgrade backtrace
    • 498843 Upgrade with VNC asks for password after reboot
    • 496311 Preupgrade fails can't read kick start file
  • [jlaska] - ensure the failing disk drive issue is tracked in bugzilla and get a Release note documented for running smartctl
    • No action here
    • wwoods pointed to 495956 Ignore some failing SMART attributes
  • [wwoods] - review F11Blocker SELinux bugs
    • there's not a lot of SELinux-specific stuff that I remember from the blocker list
    • 469257 selinux policy and mozplugger do not get along
  • [jlaska] - review F11Blocker anaconda bugs
    • Great discussion on fedora-list and fedora-test-list this past week. I've been working to connect reporters with developers to fast track defect resolution
    • The majority of issues seem related to dmraid and previous disk layout integration
  • [adamw] - continue review of X11 bugs and volume control issues

Autoqa update

F-11 Volume control update

  • adamw noted that pavucontrol will not be shipped by default for f11. There will be two mixers, the new gnome-volume-control (a Pulse-style mixer) and gst-mixer

F-11-GA Prep

Open discussion

Defining Release Candidate testing

jlaska asked whether providing "official" test summaries around areas tested, areas not tested, known issues would be useful for release engineering to make a decision. Jesse indicated he dislikes making the release decision by himself, especially when it's late at night and no one is around.

jlaska asked if there is value in defining how the release candidate phase works now? Jesse approved and recommended a separate meeting to discuss further.

Take aways ...

  • Begin documenting how the release candidate phase works now
  • Experiment during F12 with scheduled release meetings

Needs Retesting

While reviewing SELinux Block bugs, jlaska asked if we had a stock response for requesting retesting. Adamw noted that a "please retest" didn't yet exist in BugZappers/StockBugzillaResponses. Jesse pointed to the RSS feed for NEEDS_TESTING bugs (http://feeds.feedburner.com/NeedsRetesting).

This led to discussion on how Rawhide bugs work through the system. Adamw recommended just closing as fixed when the developer checks in something they're pretty sure fixes it. Jesse & Will reminded that during freezes, bugs shouldn't transition to CLOSED/RAWHIDE until the package has been tagged for rawhide. It was discovered that the wiki page BugZappers/BugStatusWorkFlow didn't capture closing bugs for rawhide, only stable releases. Adam took an action item to update.

RelEng Proposal to drop Alpha

viking_ice reminded that a proposal is circulating for dropping F12 Alpha. Jesse directed folks to fedora-devel-list (https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00311.html) to participate in the discussion.

Upcoming QA events

Action items

  • [wwoods] - write a few more upgrade cases (encrypted root upgrade)
  • [adamw] - update BugZappers/BugStatusWorkFlow wiki page to include MODIFED->CLOSE process for rawhide bugs during freeze

IRC Transcript

Pip | So there will be a meeting at midnight, right ? May 06 11:34
inode0 | looking for any meeting in particular? May 06 11:35
Pip | I mean 16:00 UTC on Wednesday May 06 11:36
Pip | inode0, Yeah, I am looking forward to attending a QA meeting May 06 11:36
inode0 | every hour is midnight somewhere :) May 06 11:37
Pip | But I'm not a conventioner, I will just listen May 06 11:37
Pip | inode0, Yeah, I mean locally May 06 11:37
Pip | brb May 06 11:38
wwoods | yep - 20 minutes May 06 11:38
Pip | that's wonderful May 06 11:38
--- | jlaska has changed the topic to: Fedora QA Meeting | gathering May 06 11:58
jlaska | QA meeting time, show of hands May 06 12:01
* | adamw shows some leg May 06 12:01
jlaska | :) May 06 12:02
jlaska | adamw: this will be a quick meeting then :) Anyone else around for todays QA meeting? May 06 12:02
adamw | there should be May 06 12:03
adamw | i think we have pip lurking May 06 12:03
jlaska | Pip: welcome :) May 06 12:03
adamw | and viking_ice and wwoods were active on the qa channel May 06 12:03
adamw | viking said he ran to get coffee so i guess he'll be back in a minute... May 06 12:04
* | wwoods back May 06 12:04
wwoods | jlaska: I thought you were gonna be gone? May 06 12:04
adamw | he lied May 06 12:04
jlaska | wwoods: so did I, appt went much quicker than expected May 06 12:05
jlaska | okya, so I have adamw, Pip wwoods and viking_ice on route May 06 12:05
--- | jlaska has changed the topic to: Fedora QA Meeting | Agenda - https://www.redhat.com/archives/fedora-test-list/2009-May/msg00288.html May 06 12:05
jlaska | I posted a planned agenda, but we can adjust as needed May 06 12:06
jlaska | let's do a quick wrap-up from last week May 06 12:06
--- | jlaska has changed the topic to: Fedora QA Meeting | previous meeting follow-up May 06 12:06
jlaska | [jlaska] - transfer autoqa tasks into TRAC instance with milestones May 06 12:06
jlaska | I lagged on that until this morning ... but started peppering the trac instance with a few milestones and the tasks f13, wwoods and I discussed May 06 12:07
jlaska | The F11 autoqa milestone can be found at https://fedorahosted.org/autoqa/milestone/Fedora%2011 May 06 12:07
Pip | jlaska, Hi May 06 12:07
Pip | Thanks guys May 06 12:07
wwoods | yeah I've been caught up in F11 testing and some work administrivia, but I'll be working on autoqa stuff after meetings today May 06 12:07
Pip | I'm here for listening something about QA May 06 12:07
jlaska | Pip: great, we're walking through the posted agenda, but please feel free to share thoughts/ideas/opinions May 06 12:08
jlaska | wwoods: sweet, we'll save the rest for the autoqa update shortly ... May 06 12:08
jlaska | # [wwoods] - checking for a bug about an upgrade issue May 06 12:08
jlaska | wwoods: I failed to capture that item last week, you had mentioned you were tracking down a [pre]upgrade issue? May 06 12:09
wwoods | there's a bunch of 'em - hence my near-constant upgrade testing. the first one I don't have a bug ID for, but it's an SELinux issue May 06 12:09
wwoods | been working with dwalsh on that (he pointed it out) May 06 12:09
wwoods | let's see, uh May 06 12:10
wwoods | bug 494995 May 06 12:10
bugbot_ | Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=494995 high, low, ---, anaconda-maint-list, CLOSED RAWHIDE, Aborting upgrade of F10 to F11-beta leaves system unbootable May 06 12:11
jlaska | are the upgrades your doing match the test procedure lili wrote up, or are these preupgrade? May 06 12:11
wwoods | I've been doing only preupgrade May 06 12:11
jlaska | wasn't sure if there's any test overlap (https://fedoraproject.org/wiki/Category:Upgrade_system) May 06 12:11
wwoods | bug 496618 May 06 12:12
bugbot_ | Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=496618 medium, medium, ---, anaconda-maint-list, MODIFIED, bootloader.images.getDefault() returns None May 06 12:12
wwoods | preupgrade does 'update bootloader config' by default May 06 12:12
wwoods | so it would correspond to https://fedoraproject.org/wiki/QA:Testcase_Anaconda_Upgrade_Update_Bootloader May 06 12:12
jlaska | ah nice May 06 12:13
jlaska | wwoods: is there additional testing/investigation you'd like folks to help with? May 06 12:14
jlaska | (on the upgrade front) May 06 12:14
wwoods | yeah - I need to write down a few more upgrade cases May 06 12:14
wwoods | there's a bug with preupgrade + encrypted root right now May 06 12:15
wwoods | that's bug 499321 May 06 12:15
bugbot_ | Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=499321 medium, medium, ---, anaconda-maint-list, NEW, preupgrade backtrace May 06 12:15
wwoods | there was a bug with preupgrade-cli + vnc passwords - bug 498843 - that needs confirmation May 06 12:16
bugbot_ | Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=498843 medium, low, ---, skvidal, ASSIGNED, Upgrade with VNC asks for password after reboot May 06 12:16
wwoods | same for preupgrade + /boot on RAID - bug 496311 May 06 12:16
bugbot_ | Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=496311 medium, low, ---, skvidal, CLOSED WONTFIX, Preupgrade fails can't read kick start file May 06 12:16
wwoods | preupgrade-1.1.0pre3 was built yesterday, I'm going to file the update requests sometime today and try to arrange some testing May 06 12:17
wwoods | actually, I guess I should wait on the update requests and just do the testing and then build 1.1.0 (final) once it looks OK May 06 12:17
wwoods | so, yeah, look for some new upgrade test cases to be written May 06 12:18
jlaska | seems sensible May 06 12:18
wwoods | and then a request for testing help on fedora-test-list May 06 12:18
jlaska | great, upgrades are an area in need of some formal test cases May 06 12:18
jlaska | wwoods: any other updates on that front? May 06 12:19
* | f13 is here now, sorry May 06 12:19
jlaska | f13: welcome May 06 12:19
wwoods | not really - although I think the virt test day might help with the preupgrade testing - create an F10 VM and upgrade it, and if it fails.. oh well! May 06 12:20
jlaska | true May 06 12:20
jlaska | okay next up ... May 06 12:20
jlaska | * [jlaska] - ensure the failing disk drive issue is tracked in bugzilla and get a Release note documented for running smartctl May 06 12:20
jlaska | I've done nothing on this issue :( May 06 12:20
wwoods | I just noticed a bug about this issue, actually May 06 12:20
wwoods | bug 495956 May 06 12:20
bugbot_ | Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=495956 medium, low, ---, davidz, CLOSED RAWHIDE, Ignore some failing SMART attributes May 06 12:20
jlaska | I intended to follow-up on the mailing list with the few threads on this topic, but that fell off my radar May 06 12:21
wwoods | new builds have been done and tags requested May 06 12:21
wwoods | so the issue is very much on the developer radar May 06 12:21
wwoods | (davidz/lpoetter are discussing it on the internal RH IRC network right now, in fact) May 06 12:22
jlaska | awesome, thanks to tmraz+davidz for getting that bug filed+processed May 06 12:22
jlaska | should we leave this open for follow-up this week? May 06 12:22
jlaska | I'll keep it open and catch up w/ davidz/lennart May 06 12:23
jlaska | next up ... the general F11-Blocker list scrubbing May 06 12:24
<-- | itami [n=itami@h219-110-132-244.catv02.itscom.jp] has left #fedora-meeting ( ) May 06 12:24
jlaska | * [wwoods] - review F11Blocker SELinux bugs May 06 12:24
jlaska | * [jlaska] - review F11Blocker anaconda bugs May 06 12:24
jlaska | * [adamw] - continue review of X11 bugs and volume control issues May 06 12:24
jlaska | wwoods: do you want to take SELinux first? May 06 12:24
wwoods | sure? there's not a lot of SELinux-specific stuff that I remember from the blocker list May 06 12:26
wwoods | bug 469257 is MODIFIED - iirc there's mozplugger build that should fix this May 06 12:28
bugbot_ | Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=469257 medium, medium, ---, than, MODIFIED, selinux policy and mozplugger do not get along May 06 12:28
wwoods | https://fedorahosted.org/rel-eng/ticket/1725 May 06 12:28
wwoods | needs retesting May 06 12:28
jlaska | adamw: do we have a template/stock_response for needs retesting on bugs? May 06 12:28
adamw | i don't believe so, but let me check May 06 12:29
adamw | no May 06 12:29
adamw | https://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses May 06 12:29
* | jlaska clicky May 06 12:29
adamw | one could be added there, i suppose May 06 12:29
Pip | So as a QA guy, python programming is required ? May 06 12:29
wwoods | and bug 490323 looks to be a system-config-date bug May 06 12:29
bugbot_ | Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=490323 medium, low, ---, nphilipp, MODIFIED, SELinux is preventing gpm (gpm_t) "read" etc_t. May 06 12:29
wwoods | I haven't seen a build for that yet May 06 12:30
wwoods | but I'm not really sure what makes this a blocker May 06 12:30
jlaska | Pip: in general no, only if you're interested in developing python-based test scripts/tools May 06 12:30
Pip | I see May 06 12:30
jlaska | adamw: the normal workflow will have all these MODIFIED bugs just move to CLOSED RAWHIDE May 06 12:30
jlaska | do folks think there's value in doing a mass update of MODIFIED bugs for retesting? May 06 12:31
adamw | personally i'm usually in favour of just closing as fixed when the developer checks in something they're pretty sure fixes it May 06 12:31
adamw | bug can always be re-opened if it turns out not to be fixed May 06 12:31
adamw | but i'm not sure what the official process is presently, just a tick May 06 12:31
* | viking_ice jumps in late in the game.. May 06 12:31
f13 | I can see it either way May 06 12:32
jlaska | same May 06 12:32
adamw | bah, i can't find the picture. heh May 06 12:32
adamw | anyone remember where it is? May 06 12:32
f13 | I don't want to see it go to closed->RAWHIDE until the package has been tagged for rawhide. May 06 12:32
f13 | important during freezes May 06 12:32
f13 | but if the maintainer is sure it's fixed, closed is fine. IF they think it's fixed, MODIFIED with a needs retesting flag would be in order May 06 12:33
wwoods | In my opinion the bugs really shouldn't be closed until the package containing the fix is available May 06 12:33
f13 | we even have a rss feed for bugs that need retesting May 06 12:33
wwoods | under normal circumstances, closing a bug RAWHIDE immediately after a build works OK, 'cuz the build will appear automatically the next day May 06 12:33
f13 | wwoods: that's what I meant, although waiting a day for the rawhide compose to happen is a bit... lame. May 06 12:33
wwoods | but during a freeze you gotta wait for the tag to happen May 06 12:34
f13 | if only we had a message bus that could tell us when a package is actually available and automatically close the bug for us... May 06 12:34
adamw | =) May 06 12:34
viking_ice | f13: can you post on the test list how to subscribe etc for the retesting bugs May 06 12:34
* | adamw still looking for that darn picture May 06 12:34
viking_ice | or put that on the QA space on the wiki May 06 12:34
f13 | I thought it was May 06 12:34
f13 | I thought that's where I got it from, the triage pages somewhere May 06 12:34
viking_ice | triagers != testers May 06 12:35
f13 | yeah, I'm not sure where I got it May 06 12:35
adamw | clearly this means the wiki isn't done yet, heh May 06 12:35
jlaska | a living document :) May 06 12:35
viking_ice | :) May 06 12:35
f13 | http://feeds.feedburner.com/NeedsRetesting May 06 12:35
f13 | that's the feed May 06 12:35
jlaska | f13: thx May 06 12:35
jlaska | 3 bugs May 06 12:36
f13 | http://fedoraproject.org/wiki/QA/Join listed there May 06 12:36
adamw | actually i'm surprised developers don't complain about this May 06 12:36
jlaska | adamw: in what way? May 06 12:36
adamw | it's another area i had experience of at mdv May 06 12:36
jlaska | that the bugs don't get tested, or they sit there in MODIFIED? May 06 12:36
adamw | when i first designed the triage process there, bugs couldn't be closed until the fixed package was available (whatever that meant for the release in question) May 06 12:36
f13 | there is some RHT history here May 06 12:37
adamw | but the maintainers whined like hell so it got changed to "you can mark it as fixed as soon as you check it into SVN" May 06 12:37
viking_ice | f13: ok I need to start putting together some testers/reporters page under the QA namespace May 06 12:37
f13 | in RHEL, developers rarely have to tiddle a bug status, once they've done a build and threw it at the errata system, the errata system takes care of all bug state maintenance. May 06 12:37
viking_ice | can we deliver rss feed per component ( thinking a bit ahead here ) May 06 12:37
f13 | bodhi does that for us to some extent May 06 12:38
f13 | viking_ice: I don't know, do some research? (: May 06 12:38
viking_ice | f13: ok May 06 12:38
f13 | but in rawhide, we leave it up to our maintainers to twiddle states without a whole lot of guidance. May 06 12:38
jlaska | I think in RHEL, it started with some documentation/guidance on the lifecycle ... and the tooling suported it May 06 12:38
f13 | nod May 06 12:38
f13 | we have some guidance May 06 12:38
adamw__ | gack May 06 12:38
adamw__ | my vpn connection died right at "<viking_ice> f13: ok I need to start putting together some testers/reporters page under the QA namespace" May 06 12:38
adamw__ | what'd i miss? May 06 12:39
jlaska | definitely ... is it worth thinking about documenting/defining a bug's lifecycle for rawhide then? May 06 12:39
f13 | <f13> in RHEL, developers rarely have to tiddle a bug status, once they've done a build and threw it at the errata system, the errata system takes care of all bug state maintenance. May 06 12:39
f13 | <viking_ice> can we deliver rss feed per component ( thinking a bit ahead here ) May 06 12:39
f13 | <f13> bodhi does that for us to some extent May 06 12:39
f13 | viking_ice: I don't know, do some research? (: May 06 12:39
f13 | http://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow May 06 12:39
jlaska | there's the pic May 06 12:39
adamw__ | that's what i was lookin for. May 06 12:39
f13 | this mostly concerns itself with updates May 06 12:39
f13 | (wiki search for "life cycle" turned it up) May 06 12:39
f13 | I know, it's weird, our wiki search actually works May 06 12:40
adamw__ | i searched 'bug cycle' May 06 12:40
adamw__ | no joy there May 06 12:40
adamw__ | anyhoo May 06 12:40
adamw__ | that clearly covers stable releases, so yeah, there's a hole there May 06 12:40
-- | wolfe.freenode.net <- irc.freenode.net quits: jcollie, kulll_, pjones, herlo, tagoh3, JSchmitt, pknirsch, wwoods, JukeBoxHero, rdieter, (+47 more) May 06 12:40
f13 | not much of a hole though May 06 12:40
f13 | and we split. May 06 12:40
f13 | *sigh* May 06 12:40
adamw__ | oh for the love of... May 06 12:40
f13 | looks like most of us are still here though May 06 12:41
f13 | except for wwoods May 06 12:41
* | viking_ice has a reliable internet connection.. May 06 12:41
viking_ice | yes true May 06 12:41
adamw__ | it's not about *your* connection May 06 12:41
--> | Netsplit Over - Joins: Pikachu_2014 May 06 12:41
f13 | viking_ice: this is a network split May 06 12:41
adamw__ | just what side of the split you're on May 06 12:41
viking_ice | always on the side that works apparently.. May 06 12:41
f13 | really the only thing missing in this graphic for rawhide is the parts after MODIFIED May 06 12:41
adamw__ | yeah May 06 12:41
jlaska | so a new mini-decision tree May 06 12:42
jlaska | update release ---> Yes May 06 12:42
jlaska | | May 06 12:42
adamw__ | as i said, personally i'm in favour of letting devs close the bug as soon as they commit and tag (if it's outside of a freeze) May 06 12:42
jlaska | No May 06 12:42
adamw__ | simpler for everyone, usually correct, and easy enough to handle if it's not: just re-open the bug May 06 12:42
--> | Netsplit Over - Joins: rdieter May 06 12:43
--> | Netsplit Over - Joins: basilgohar, pjones, jeremy, N3LRX, mbonnet, dwmw2_gone, davej, danielbruno, kolesovdv May 06 12:43
jlaska | I think we can do better long term, but given where we are, yeah I agree May 06 12:43
jlaska | okay, so what's the summary for the bug life cycle ... need-retest? May 06 12:44
adamw__ | so, proposal: we allow that, devs can also use 'modified' to request testing of rawhide bugs prior to closing if they like, but if they do, the bugs can be set to CLOSED RAWHIDE automatically (or manually, or semi-automatically) if no re-testing actually happens within, oh, two weeks? May 06 12:44
f13 | needretest is useful if the maintainer wants to get more validation of the bug May 06 12:44
f13 | but not necessary May 06 12:44
jlaska | true, it fits the opt-in approach common now with our handling of bugs May 06 12:45
f13 | adamw__: we should probably match that timeout up with a timeout for NEEDINFO requests. May 06 12:45
viking_ice | Some of them just close it with WORKSFORME others ask for retesting... May 06 12:45
adamw__ | i mean, it's rawhide. y'know. we're not working with RHEL levels of quality here. heh. May 06 12:45
f13 | WORKSFORME isn't a valid closure for a fixed bug May 06 12:45
adamw__ | right May 06 12:45
f13 | it's a closure for "NOTABUG" but not as mean May 06 12:45
adamw__ | the valid closure for fixed rawhide bugs is RAWHIDE, and nothing else May 06 12:45
adamw__ | or "i can't reproduce and there's no way i can fix it if i can't reproduce" May 06 12:45
f13 | adamw__: are we disallowing the use of CLOSED->UPSTREAM? May 06 12:46
viking_ice | ? May 06 12:46
adamw__ | that's not a closure for a bug fixed in rawhide directly, though May 06 12:46
adamw__ | you don't use it at the point the bug's fixed May 06 12:46
f13 | no, it's not, however it does get used. May 06 12:46
--- | irc.freenode.net sets modes [#fedora-meeting +o ChanServ] May 06 12:47
f13 | if we're going to define policy, might try to cover the usage of that s well. May 06 12:47
adamw__ | as i said, RAWHIDE is the only resolution for *a bug a developer just fixed by checking some code into rawhide* :) May 06 12:47
adamw__ | yeah, we're a bit off-topic now though May 06 12:47
-- | Netsplit wolfe.freenode.net <- irc.freenode.net quits: herlo, G, ivazquez May 06 12:47
adamw__ | and that's part of something bugzappers is working on right now May 06 12:47
adamw__ | so may as well leave it alone here May 06 12:47
--> | Netsplit Over - Joins: ivazquez, G, herlo May 06 12:47
jlaska | adamw__: anything we need to get down for next week here, or continue discussion in the BugZapper meetings? May 06 12:47
adamw__ | i think we settled the important bit...and i can take an action item to update the wiki page May 06 12:47
--- | adamw__ is now known as adamw May 06 12:47
Pip | What if we can't resolve all the bugs reported by the release day ? May 06 12:48
viking_ice | that never happens May 06 12:48
adamw | Pip: heh, if only we could :) there's a process for that May 06 12:48
adamw | Pip: bugzappers has a process for managing all open bugs in rawhide when a release is made; basically they get changed to be for that release May 06 12:48
Pip | adamw, The entire life cycle is controlled or designed by ... the Fedora architect ? May 06 12:49
adamw | so when we release 11, all open rawhide bugs will be changed to be 11 bugs May 06 12:49
--- | jlaska has changed the topic to: Fedora QA Meeting | autoqa update May 06 12:49
adamw | Pip: er...it's controlled or designed by us, and the bugzappers, and the maintainers, in a chaotic and loosely-defined fashion, like everything else around here =) May 06 12:49
viking_ice | the most recent report that I filed that is supposed to be fixed was set on MODIFIED status.. May 06 12:49
jlaska | held together w/ bubble gum and chicken wire May 06 12:49
wwoods | oh hey! we're back! May 06 12:49
f13 | wwoods: welcome to the dark side May 06 12:50
adamw | wwoods: sorry, you got caught on the wrong side of splitsville May 06 12:50
viking_ice | welcome to the world of tomorrow. May 06 12:50
adamw | Pip: practically speaking, we'll change the document, let people know, hopefully everyone agrees and it will be applied in practice, if not it gets revisited somehow in the future May 06 12:50
adamw | Pip: it's a fairly vague way of doing things but mostly it works :) May 06 12:50
f13 | adamw: if you come up with good policy, that will help me when designing the message bus and tools on top of it to automate some of that policy May 06 12:50
adamw | sure May 06 12:50
f13 | so that we can take the bug status management hassle out of the hands of maintainers/triagers and put it into software. May 06 12:51
adamw | i'll drop a quick note on the discussion here to -devel-list later May 06 12:51
Pip | I see May 06 12:51
jlaska | okay, unless any other points ... changing topics to autoqa May 06 12:51
adamw | so, we're running over, jlaska, take us to the bridge :) May 06 12:51
viking_ice | we always ( well most of the time ) run over.. May 06 12:52
f13 | (cvs changelog mentions "resolves bug #foo" and some bit twiddles bug #foo to the right state, new rawhide report changelog mentions fixing bug #foo, we twiddle bug state accordingly, etc...) May 06 12:52
jlaska | wwoods: we touched on it briefly earlier, but do you want to give an update on the autoqa project May 06 12:52
wwoods | no major changes to report - we've been discussing things that need doing May 06 12:52
wwoods | including 1) handling the F9 'newkey' repos for post-repo-update tests May 06 12:53
f13 | I beat together an example of a conflicts finder, discovered some issues along the way May 06 12:53
wwoods | and 2) scheduling/queueing tests so they don't all run at once May 06 12:53
f13 | I'm going to rewrite the finder a bit to make it more conform to the future of yum-utils software May 06 12:53
wwoods | I note that the beaker setuphowto has been updated: https://fedorahosted.org/beaker/wiki/SetupHOWTO May 06 12:54
jlaska | f13: I'm psyched about the conflicts detection, thanks for your efforts there May 06 12:54
f13 | wwoods: nice! May 06 12:54
jlaska | wwoods: that's mostly with respect to setting up the lab-mgmt component May 06 12:54
f13 | jlaska: yeah, I'm a bit excited about it too as it's something that needs some real attention May 06 12:54
wwoods | jlaska: right - that side is kind of working from the top down - machine/distro management May 06 12:55
jlaska | right on May 06 12:55
wwoods | and it seems like we're working the other way - start with the tests we want to run and write stuff around 'em May 06 12:55
wwoods | I hope we meet in the middle somewhere May 06 12:55
jlaska | I'm not too concerned, bpeck was excited to see you use the rhtslib format May 06 12:56
wwoods | probably I should discuss scheduling and things with bpeck et. al. to make sure anything we duct-tape together will be compatible with whatever they may be working on May 06 12:56
adamw | (side note: I just updated https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow to be more explicit about closed and modified as discussed above) May 06 12:57
jlaska | adamw: thx! May 06 12:57
jlaska | wwoods: not a bad idea, just to keep a running list of possible pain points May 06 12:57
jlaska | wwoods: take a look at the tickets I assigned too. Please let me know if these are representative of what needs tackling this month for F11 May 06 12:58
wwoods | right, will do May 06 12:59
jlaska | okay ... changing gears ... May 06 12:59
--- | jlaska has changed the topic to: Fedora QA Meeting | volume control update May 06 12:59
jlaska | adamw: wanted to give you a chance to update folks on where things are with FESCO's volume control decision May 06 13:00
adamw | it's all done May 06 13:01
viking_ice | ? May 06 13:01
adamw | gst-mixer is in f11 repos and in comps May 06 13:01
viking_ice | Are them both installed or May 06 13:01
jlaska | sweet and simple! May 06 13:01
adamw | will be installed by default for f11 release (default dvd release, and gnome spin) May 06 13:01
adamw | it is the old gnome-volume-control May 06 13:01
adamw | testing is appreciated - basically, make sure it works for you as it did in f10 May 06 13:02
adamw | it is on the menus in Sound & Video with the name 'Advanced Volume Control' May 06 13:02
wwoods | for the record: it *wasn't* in F11Preview or earlier, so anyone who installed their system before F11 might want to install gst-mixer by hand May 06 13:02
adamw | pavucontrol will not be shipped by default for f11 May 06 13:02
adamw | so there will be two mixers, the new gnome-volume-control (a Pulse-style mixer) and gst-mixer May 06 13:02
adamw | that's that. :) May 06 13:02
jlaska | adamw: a fitting short summary for that one May 06 13:03
jlaska | thanks for your efforts here May 06 13:03
--- | jlaska has changed the topic to: Fedora QA Meeting | F-11-GA May 06 13:04
viking_ice | so In f12 we can have both pidgin and empathy install ( easing the migration process ) May 06 13:04
viking_ice | by install I mean installed.. May 06 13:04
viking_ice | I think by going ahead and choose this method after feature freeze is opening a can of worms.. May 06 13:05
viking_ice | but ok May 06 13:05
jlaska | we're running late, but I did want to bring up the topic of test summary reports May 06 13:06
* | viking_ice notes that perhaps f13 and or wwoods mention the removal of alpha milestone.. for the record May 06 13:06
wwoods | ah, yes, that's worth a moment too May 06 13:06
jlaska | my thinking is this would provide a summary of testing against F11 release candidates ... list of known issues, items tested, items not tested May 06 13:06
f13 | that's a good point May 06 13:06
jlaska | thanks for reminder, we'll bring that up too May 06 13:07
wwoods | jlaska: a release-wide summary? May 06 13:07
jlaska | wwoods: starting with milestone specific summary of what we know May 06 13:07
viking_ice | well if we are going to produce summaries we should do so on each miles stone ( track progress ) May 06 13:08
jlaska | specifically around the release candidate drops, I'd like to document/formalize the expectations around them May 06 13:08
viking_ice | is this not something we should implement in the F12 cycle? May 06 13:09
jlaska | most certainly May 06 13:09
jlaska | on the test summary angle, I'm curious how folks feel about it May 06 13:09
jlaska | who releases the rc's ... when do they do it, would providing guidance from fedora qa help? May 06 13:10
jlaska | f13: would defining the handoff be helpful for you when deciding to push a RC out to mirrors? May 06 13:11
* | viking_ice is totally lost with the test summary angle.. first what do we want to summarize ? May 06 13:11
f13 | yeah, I hate making that call by myself. May 06 13:11
f13 | although often it's late at night and nobody is around. May 06 13:11
jlaska | f13: should we get it in the schedule at a reasonable time for folks? May 06 13:12
f13 | I think we can experiment with it in F12 May 06 13:12
jlaska | yeah that's definitely a good time to get things going, but I was curious if there were any baby steps we could try now May 06 13:12
jlaska | nothing major May 06 13:12
viking_ice | do we want/need to puch rc to the mirrors ( use shared torrent only ) May 06 13:13
wwoods | not enough time for RC to go to mirrors May 06 13:13
viking_ice | thought so May 06 13:13
f13 | when the RC drops the C and become R it has to go May 06 13:13
wwoods | well, hmm May 06 13:13
jlaska | f13: what's tough for me is that I don't know when they'll land May 06 13:14
wwoods | do we usually put the RC bits on the mirrors and just keep them locked as we make new RCs? May 06 13:14
f13 | no May 06 13:14
jlaska | and then I'd like to improve the data needed when go/no_go time comes May 06 13:14
f13 | we put them in the stage spot May 06 13:14
f13 | I also put them if I have time on the master mirror but locked to the other mirrors May 06 13:14
f13 | once mirrors get a hold of content, there is high likelyhood of leaks May 06 13:15
jlaska | f13: is there value in us spending some time to outline how it works now? May 06 13:16
wwoods | true - and we really don't want incomplete RCs leaked as "final" May 06 13:16
jlaska | I'd like to figure out the best way for QA to engage with how the RC's are built ... and how best to provide feedback May 06 13:17
f13 | jlaska: as a separate meeting, sure. May 06 13:17
f13 | jlaska: since it involves more than just QA and me May 06 13:17
jlaska | ah great point May 06 13:17
jlaska | f13: who should the participants be? May 06 13:17
--- | openpercept_ is now known as openpercept May 06 13:18
f13 | QA, releng, um... May 06 13:18
f13 | hrm. May 06 13:18
f13 | sig leaders I suppose May 06 13:19
jlaska | f13: okay, I'll catch up with you after this for some guidance. May 06 13:19
f13 | here lies the problem. The more people we include the longer it takes to reach a decision. The less people we include the more chance there is for missing something. May 06 13:19
jlaska | certainly May 06 13:19
jlaska | at this point I'm more in data gather mode May 06 13:19
f13 | k May 06 13:20
viking_ice | is not QA an Releng enough ? the sig needs to follow that what ever comes out of it? May 06 13:20
f13 | viking_ice: could be enough. May 06 13:20
--- | jlaska has changed the topic to: Fedora QA Meeting | Open Discussion May 06 13:21
viking_ice | faster decision being made that decision can then just be revisited if needed May 06 13:21
jlaska | viking_ice: you raised the discussion around dropping the Alpha milestone May 06 13:21
f13 | hard to revisit a decision to release bits to the mirror. May 06 13:21
viking_ice | ok May 06 13:22
jlaska | if nothing else, we can document how it works now May 06 13:22
jlaska | which will be a big help when that bus that keeps hitting people comes around May 06 13:22
viking_ice | Yes a decision was made on the last FESCo meeting about dropping the alpha milestone ( see https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2009-may-04 ) May 06 13:23
f13 | that wasn't a FESCo meeting May 06 13:23
f13 | that was a releng meeting May 06 13:24
f13 | and it was a decision to propose dropping it May 06 13:24
viking_ice | I meant Releng meeting sorry my bad ( link correct ) May 06 13:24
jlaska | f13: where does the proposal go now, how can people get involved? May 06 13:24
f13 | Now it went to the mailing lists where there has already been some discussion, and ultimately it goes to FESCo May 06 13:26
viking_ice | well we need to remove any reference to alpha I suppose ( wiki work ) May 06 13:26
viking_ice | that is if approved.. May 06 13:26
viking_ice | perhaps a summary of why this was propose and what benefits it has over the current process is in order? May 06 13:27
<-- | ppeev [n=ppeev@88.203.247.82] has left #fedora-meeting ( ) May 06 13:27
* | poelcat wonders how it would help QA May 06 13:27
wwoods | it's not in the meeting notes? huh May 06 13:27
f13 | I outlined some of why in the mail response I made. May 06 13:27
jlaska | my initial concern is that it will impact when we can start F12 test days May 06 13:28
viking_ice | not really May 06 13:28
adamw | (ok, side note again: i got inspired, and https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow is now, er, a lot better. and bigger. and in the right order.) May 06 13:28
wwoods | anyway the Alpha release sets unrealistic expectations for the release, since it usually doesn't contain most of the features that are supposed to be in the release May 06 13:28
wwoods | and it takes time away from other, more focused testing May 06 13:28
f13 | https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00227.html is the start of the thread. May 06 13:28
viking_ice | jlaska: We compose a live image for each test day right :) May 06 13:28
wwoods | and time away from regular development May 06 13:28
jlaska | viking_ice: we can and do ... when they work May 06 13:29
jlaska | f13: thanks May 06 13:29
f13 | jlaska: I would assume that test days can still be done, perhaps even earlier if a given feature is ready for some form of testing May 06 13:29
viking_ice | thus no impact on when we start test days ( as long as the images work ) May 06 13:29
f13 | basically alpha was dubious. It doesn't match what is typically called an "Alpha" in software dev, particularly because it was made public and not an internal thing May 06 13:29
wwoods | right - it's much more valuable to have focused test days for the features that *are* ready May 06 13:29
wwoods | rather than an alpha image that has a bunch of random crap in various stages of completion May 06 13:30
viking_ice | then again a semi working rawhide is needed ( atleast for the components that are being tested ) May 06 13:30
jlaska | that didn't always work as expected May 06 13:30
f13 | the most value I saw out of it was a "known good starting point" to get on rawhide, and we've failed at that more often than not May 06 13:30
viking_ice | has that ever been a good starting point May 06 13:30
f13 | with F12 being so short, the F11 GA can provide the "known good" to get on rawhide. May 06 13:30
f13 | until we get to Beta May 06 13:30
jlaska | f13: I'm a fan of milestones, while it's often difficult to meet them, I'm not sure I fully understand the motivation to drop them May 06 13:31
f13 | https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00311.html sums up my thoughts pretty well. May 06 13:31
jlaska | f13: okay, we'll keep things short here and folks can follow up with any concerns May 06 13:32
f13 | jlaska: I'm a fan of useful milestones. the most often feedback I get on the Alpha milestone from developers is that it's a useless distraction that keeps them from getting things ready in time for Beta. May 06 13:32
* | viking_ice says go forward with it.. May 06 13:32
adamw | +1 for f13 May 06 13:33
viking_ice | +1 May 06 13:33
jlaska | I agree on the useful point, I'm just not sure I understand the response May 06 13:33
viking_ice | Worst case scenario we revert to previous process during F13 cycle ( or revisited and improve ) May 06 13:33
f13 | yep May 06 13:34
f13 | like everything, its an experiment. May 06 13:34
* | jlaska missing cause/effect May 06 13:34
f13 | We tried to make alpha a non-blocking freeze to remove some of the delays, but that didn't work for some critical parts of development, anaconda being one of them. May 06 13:34
f13 | jlaska: this isn't specifically an attempt at fixing something wrong, first and foremost it's an attempt to maximize the very small development time for F12 May 06 13:35
viking_ice | we also get rid of alpha not working nuance ( testers just install a working copy and upgrade ) May 06 13:36
jlaska | my cautionary note is that the test days aren't freebies. We've had a few fail to start since we were blocked by other bugs (sometimes anaconda, sometimes not) May 06 13:37
jlaska | I just worry that if there's no incentive to line content up in time ... hosting successful test days may be impacted May 06 13:37
viking_ice | ah yes we need schedual better what to test and when in the process ( mostly our fault ) May 06 13:37
viking_ice | for instance no DE related testing until Beta ( though experience should have tough us that by now ) May 06 13:38
viking_ice | as in no gui test until beta May 06 13:38
jlaska | viking_ice: there are a lot of factors when it comes to scheduling them, I'm not ready to accept the blame on that one :) May 06 13:39
jlaska | f13: thanks for the links ... I'll reply with any concerns on the list May 06 13:39
viking_ice | hear you man perhaps you should get wider feed back on what to test and when May 06 13:39
viking_ice | so some of that blame can be shared :) May 06 13:40
jlaska | viking_ice: we did ... and we'll do it again for F12 May 06 13:40
jlaska | okay folks, any other discussion topics May 06 13:40
adamw | not for me May 06 13:41
viking_ice | nothing from me.. May 06 13:41
f13 | I'm good May 06 13:41
jlaska | okay folks ... thanks for your time! May 06 13:42
jlaska | minutes will be on the list soon May 06 13:42
--- | jlaska has changed the topic to: Channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | For questions about using Fedora please ask in #fedora | See http://fedoraproject.org/wiki/Meeting_channel for meeting schedule May 06 13:42
Pip | Thank you for your time as well, as a newbie of QA on Fedora, I would be learning from you : ) May 06 13:43

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!