--- Log opened Wed Jul 09 11:03:59 2008
-!- LyosNorezel [n=LyosNore@unaffiliated/lyosnorezel] has joined #fedora-meeting11:04
-!- Topic for #fedora-meeting: 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/Communicate/FedoraMeetingChannel for meeting schedule11:04
-!- Topic set by Kevin_Kofler [n=Kevin_Ko@chello213047068123.17.14.vie.surfer.at] [Tue Jul 8 13:04:40 2008]11:04
-!- wwoods changed the topic of #fedora-meeting to: Fedora QA Meeting | init11:04
* jds2001 wanders in11:04
wwoodshey, does anyone have a link to the irc -> mediawiki converter dealie?11:04
-!- alexxed [n=alex@dnt-gw-teamlingo.dnttm.ro] has quit [Read error: 104 (Connection reset by peer)]11:04
* DemonJester lurking11:05
wwoodsor, honestly, we should set up a IRC log repo webapp dealie11:05
wwoodsand by "we" I mean "someone else"11:05
jlaskawwoods: http://mg.pov.lt/irclog2html/svn/ ?11:05
wwoodsjlaska: that converts to html; does that work in mediawiki?11:05
jds2001wwoods: i know there was some talk about having a bot in here that could log11:05
jds2001i know ianweller_afk has something akin to irclog2html that converts to mediawiki tables11:06
jlaskawwoods: #   New styles: xhtml, xhtmltable, mediawiki11:06
wwoodsjlaska: sweet moustache!11:06
wwoodsjlaska: thanks, I'll check that out once the meeting is over11:06
jlaskathanks to poelcat who gave me a heads up on that11:06
wwoodsanyway; jlaska, alindebe, jds2001, poelcat, f13.. ping11:06
-!- rdieter is now known as rdieter_afk11:06
* jds2001 11:06
* jlaska 11:07
* f13 11:07
-!- j6k [n=j6k@f151080.upc-f.chello.nl] has quit []11:07
-!- wwoods changed the topic of #fedora-meeting to: Fedora QA Meeting | team composition11:08
-!- spstarr_work [n=spstarr@] has joined #fedora-meeting11:08
wwoodsso the roll call raises the question: who's actually *in* the QA team?11:08
spstarr_workwwoods: heh, anyone who helps retest bugs? :-)11:09
wwoodswell, yeah, but I don't expect them to all attend meetings11:09
wwoodspeople who I expect (well, hope) will attend QA meetings - a rep from each SIG11:09
-!- techbugs [n=siddhart@] has joined #fedora-meeting11:09
wwoodsa rep from releng (f13 usually)11:09
* f13 reps releng11:09
wwoodsjlaska, as Test Plan Ninja11:10
spstarr_workI will usually help test bugs once things freeze (downloading repos is just too much bandwidth suckage to test every snapshot ;/)11:10
jlaskaanyone got a link to the sigs?11:10
wwoodsjds2001, as Triage Guru11:10
spstarr_workas i did for F9 closing11:10
chewwoods, an important part to improve current qa for updates would be to assure that for testing updates the whole dep tree is beeing rebuilt11:10
wwoodspoelcat, as Feature Wrangler (and Triage Guru #2)11:10
wwoodsche: hold that thought11:10
wwoodsso. anyone else I should be trying to pull into QA meetings? 11:11
wwoodsaround release time I like to get a rep from the major dev teams (anaconda, kernel, X, desktop/gnome)11:11
wwoodsdo we need a FESCo rep?11:12
jds2001would be nice...but not required i dont think11:12
jlaskawwoods: what about weekly meeting qa themes ... one example might be where we can pull in "special guest" stars to talk about upcoming features11:13
wwoodsjlaska: yeah, we might want to do that to hammer out test plans for proposed features11:13
-!- rahul_b [n=rbhalera@nat/redhat-in/x-8abbe19d168c5560] has quit ["Leaving(पुन्हा भेटू)"]11:13
* stickster here, just off phone11:13
jlaskawwoods: I'd like to begin polling for folks interested in the Test Plan subteam ... with the immediate goal of building plans for upcoming F10 features11:14
* jlaska notes ... that sounds dirty11:14
jds2001oh, and stickster if he wants to i guess :)11:14
jds2001do we have any feature pages yet?11:14
wwoodssure do11:15
* jds2001 hasnt looked11:15
sticksterThere's only one that's ready for approval voting, according to something I saw from poelcat this morning11:15
wwoodsyeah, that's Haskell support11:15
jlaskastickster: great link, thx11:15
sticksterKinda makes my blog post from yesterday a little too rah-rah? :-)11:16
wwoodsha, YaakovNemoy owns that. How did I know?11:16
jlaskawwoods: stickster: what's the diff between the dashboard and the category page?11:16
wwoodsthe dashboard links to the proposed / accepted / rejected categories11:16
wwoodsand isn't specific to F1011:16
wwoodsit's the canonical starting point for this stuff, if I understand it right11:17
jlaskaah ... okay so it'll also (eventually) have F11 F12 ...11:17
wwoodsso I guess we should talk to loupgaroublond (I think that's Yaakov?) about improving the Test Plan11:17
wwoods(implicit ping)11:17
* stickster is going to start calling it the "Eddie Haskell" feature.11:18
jlaskastickster: so I can stay tuned to http://fedoraproject.org/wiki/Releases/10/FeatureList for what's been approved for F10?11:19
wwoodsso, okay, summing up: the QA "board" is now defined as wwoods, f13, jlaska, poelcat, and jds2001 - these are the people who should be in each meeting and are the main decision-makers11:20
sticksterjlaska: That's the list for currently approved features, yeah11:20
wwoodswe'd really like reps for each SIG/spin to attend11:20
wwoodsACTION: meet with owners of features up for approval to work on test plans11:21
wwoodsgood so far?11:21
* wwoods assumes yes11:22
wwoodsokay next: Testopia11:22
-!- wwoods changed the topic of #fedora-meeting to: Fedora QA Meeting | Testopia11:22
wwoodsbasically: We can't use testopia 'cuz of license problems. oh no!11:22
jlaskawell ...11:22
wwoodswell, okay11:22
jlaskawe can't package it in Fedora due to licensing right?11:23
wwoodswe can't have a public testopia instance for Fedora11:23
jlaska(which yeah means using it is a non-starter)11:23
wwoodsyes, both of these things11:23
wwoodswe still find it useful, though, so I think we're going to set up an internal one to continue tracking testing inside Red Hat11:23
-!- |moe| [n=moe@i577B5579.versanet.de] has joined #fedora-meeting11:23
jlaskaall due to the licensing of the javascript toolkit right?11:23
jds2001well the licensing thing is getting worked out I think11:23
-!- JSchmitt [n=s4504kr@p4FDD22B8.dip0.t-ipconnect.de] has joined #fedora-meeting11:23
wwoodswe will only use it until such time as we can fix the licensing or create a replacement11:24
-!- |moe| [n=moe@i577B5579.versanet.de] has left #fedora-meeting []11:24
jds2001well it's currently legal since the version of ext-js used is version 2.011:24
jds2001which is lgpl11:24
-!- sdziallas__ [n=sebastia@p57A2CAFD.dip.t-dialin.net] has quit [Read error: 110 (Connection timed out)]11:24
jds2001we cannot take am upgrade to ext-js 2.1 which becomes GPLv311:25
wwoodsf13: can you clarify here, or should we find dave or something?11:25
sticksterjds2001: Is the toolkit separately packaged?11:25
jlaskadmalcolm and jds2001 are the best informed on that subject iirc11:25
jds2001stickster: not now, but it should be11:25
* stickster is, he's sure, retreading ground, so apologies.11:25
sticksterjds2001: So if it was, a compat package *might* be workable?11:26
wwoodsyeah I only got notified earlier this morning so I'm not 100% on the details11:26
wwoodsso it's worth (re)discussing, for the record11:26
f13wwoods: uh... we're going to set something up internally to mine the data we've already created, I don't think we're going to continue using testopia for testing purposes.11:26
wwoodsf13: really? okay11:27
DemonJesterso we are back to using the wiki for testing, i take it..11:27
jds2001https://bugzilla.mozilla.org/show_bug.cgi?id=430138 is the current upstream discussion11:27
buggbotBug 430138: low, low, ---, Daniel Walsh, CLOSED CURRENTRELEASE, /dev/dmmidi has default label; rpc.mountd causes SELinux error audits11:27
wwoodsDemonJester: looks that way11:27
wwoodsactually we might not be using it internally either11:27
wwoodsI don't think we're going to touch it until this is sorted out11:27
wwoodshands off until the lawyers say so11:28
-!- sdziallas__ [n=sebastia@p57A2CAFD.dip.t-dialin.net] has joined #fedora-meeting11:28
jds2001it is most defintely murky ground we dont wanna be involved with :/11:28
f13upstream for the naughty component is supposedly working to create a foss friendly license11:29
f13but that may take a while.11:29
wwoodsso what are we going to do for Alpha?11:29
jlaskais it worthwhile considering pipelining those two activities?11:29
jds2001but im sure there's some MPL-friendly AJAX library out there....11:29
wwoodsThe "freeze" starts in.. 13 days?11:29
* jds2001 doubts anything is resolved in 13 days11:30
jlaskawiki unfortunately fits the time constraints11:30
sticksterf13: I hope that doesn't mean "creating our own new convoluted license." :-\11:30
jds2001stickster: i have a feeling it's an exception to teh license *for this project* :/11:31
jds2001which i dunno if that would be acceptable or not11:31
-!- sdziallas__ [n=sebastia@p57A2CAFD.dip.t-dialin.net] has quit [Client Quit]11:31
f13stickster: I do too.11:32
f13wwoods: releng voted to push alpha out a week due to OLS11:32
sticksterjds2001: If it's not redistributable, probably not.11:32
f13and from what i can gather, the schedule has yet to be approved by FESCo11:33
wwoodsf13: July 22 is the *new* date, isn't it?11:33
wwoodsIt was supposed to be July 1511:33
-!- petreu_ [n=petreu@p3EE3EBC6.dip.t-dialin.net] has joined #fedora-meeting11:33
wwoodsI'm assuming that the schedule change will be approved. If it's not, then we've got 6 days.11:33
wwoodseither way, I think we're gonna be doing it wiki-style again11:34
wwoodson the positive side, using Testopia let us refine some of the test cases and plans we use11:35
f13well the original schedule wasn't approved either11:35
wwoodsso at least the plan should be pretty useful11:36
jlaskawwoods: yeah definitely a positive process ... not the immediate outcome we were hoping for of course11:36
wwoods(many thanks to alindebe, jlaska, and f13 for working on that stuff)11:36
wwoodsyeah, hopefully we can keep working on it, despite having to switch tools11:36
wwoodsanything else about testopia?11:37
wwoodsokay. next up: bodhi changes11:38
-!- wwoods changed the topic of #fedora-meeting to: Fedora QA Meeting | Bodhi and updates-testing11:38
wwoodsSo bodhi is supposed to be getting the ability to modify (or disable) the +3-karma-means-autopush rule11:38
wwoodswhich is good because I think we've had some mishaps with packages (e.g. kernel) getting pushed before they're really ready11:39
wwoodsche: now, what were you saying about dep trees for updates?11:40
f13wwoods: that change is supposedly live11:41
jds2001wwoods: we've had busted deps in stable recently11:41
jds2001i think that Bodhi (or releng :/ ) should check that the final outcome of a push is not bustificated.11:42
wwoodsjds2001: how?11:42
jds2001im not really concerned if updates-testing is busted, though11:42
wwoodswell, obviously we should catch it in updates-testing first11:42
jds2001i would assume something similar to how it checks rawhide11:43
jds2001rihgt, but who cares if -testing is busted? We should probably generate a report on breakage there, though11:43
wwoodsjds2001: except that check only happens once a day. doesn't the contents of updates-testing change all day long?11:43
jds2001i dont thinkk so, that's a manual push by releng I think11:44
jds2001from dist-f9-updates-candidate to dist-f9-updates-testing in koji11:44
f13-candidate changes all day long11:44
f13-testing only changes when we do a push11:44
f13the rawhide check is just a check, it doesn't /stop/ anything from happening.11:45
wwoodsso how long would it take to check whether a push to -testing would cause broken deps?11:45
f13there is a current ticket open with bodhi to enable repoclosure, but it is extremely cost prohibitive, once you take multilib into account11:45
wwoodsI assume the current algorithm for checking is to run a full repoclosure11:45
f13wwoods: many hours11:45
f13wwoods: you have to create new repos from the new set of 'latest' packages, process those repos for multilib, and then repoclosure11:45
wwoodsand if those fail.. can you prune the broken deps and only push the others? or does that mess up the repoclosure calculation and you have to run it again to be sure?11:47
f13you'd have to run it again11:47
f13if you wanted to be truly accurate11:47
f13and take into account updates where are part of a set, say one kde package out of the 20 being pushed for updates causes broken deps...11:48
wwoodsjds2001: so, yeah, it would take most of a day to check/fix deps on pushes to the updates repo11:48
wwoodsthis is a pretty convincing case for either a) less updates pushes or b) better dep checking algorithm11:49
jds2001i go for a+b :)11:49
jds2001weekly pushes except for security should be plenty imho11:49
jds2001or maybe twice a week11:49
-!- spoleeba [n=one@fedora/Jef] has joined #fedora-meeting11:50
f13slowing the push frequency isn't the answer11:50
wwoodsthat's a fairly major change11:50
f13all that does is punish the users who want to get bugfixes11:50
lmackenf13: no that change (disabling autokarma) is not live11:50
wwoodsI'd support it for a variety of reasons but it needs further discussion11:50
jds2001agreed, nothing we can decide here11:51
wwoods(It'd also reduce the average startup time for yum)11:51
lmackeni'm going to be adding deltarpm generation to the push process soon, and will also polish up bodhi's closure module11:51
lmackensince we're going to be mashing on a separate server, it won't tax the web interface11:51
lmackenand once sigul is alive, we'll be pushing a lot more often.. so slowing the push frequence is not the answer11:52
wwoodsspeeding up the process is awesome. I still think there's a case to be made for slowing update push frequency, though.11:53
jds2001just cuz we can doesnt mean we should :)11:54
wwoodsthat argument works in both directions11:54
lmackenthere is a lot of low-hanging fruit within the update push process11:54
wwoodswe can discuss slowing updates on one of the lists11:54
-!- balor [n=balor@] has quit [Read error: 110 (Connection timed out)]11:55
wwoodswe're not gonna make the decision here, though11:55
lmackenwe're already taking way too long to get security updates out the door as it is :(11:55
wwoodsbut, let's sum up: it's not currently feasible to dep-check on pushes to updates. but lmacken is a hero and he's working on it.11:55
lmackenbut yeah, that's a discussion for later11:55
wwoodslmacken: security updates would obviously be exempt.11:55
wwoodswhich is why it's still really important to speed up the push process, regardless11:56
wwoodsanyway, getting close to the 1hr mark11:56
wwoodsanything else about updates/bodhi?11:57
wwoodsI was going to talk about plans for linking bodhi to testopia, and having per-package test plans11:57
wwoodsbut alas11:57
-!- sharkcz [n=sharkcz@nat/redhat/x-f61309007deaca38] has quit ["Leaving"]11:57
lmackenyeah, I was just about to ask about the test plans11:57
lmackendidn't you start them off in the wiki somewhere ?11:57
wwoodsthat's on hold for a while, what with testopia being in legal quarantine11:57
-!- fbijlsma [n=fbijlsma@] has joined #fedora-meeting11:58
lmackenI find that there are a lot of people who are trying to churn through and actually test updates-testing... but have no idea how to do it11:58
* jds2001 being summoned to a meeting :/11:58
lmackenwwoods: it's cool, dmalcom is working on a TurboGears reimplementation ;)11:58
f13jwb: testopia uses a javascript library that has a conflicting license11:58
wwoodsso the overall plan is: each package will have a link (probably stored in pkgdb) to a test plan11:59
wwoodsthe test plans were originally going to be stored in the wiki, but then we realized that was suboptimal, so we were going to use testopia, but that has legal trouble11:59
jwbf13, oh ok11:59
wwoodsso now we're kind of up in the air11:59
wwoodswe could define a stopgap measure for people who really want to write test plans now12:00
jlaskawwoods: yeah, dmalcom is doing some investigation in the back ground ... and I'm evaluating litmus as well12:00
wwoodsexample stopgap: you can create TestPlans/[packagename] in the wiki, and if that exists, the bodhi/pkgdb pages that involve that package can show a link12:00
jlaskawwoods: test plans on the wiki still is a good idea as far as I'm concerned (since those can be easily migrated into $tool).  Storing test results on the wiki is a different story12:00
lmackenwe shouldn't let that stop the plans from being written... why not just create a repo with flat files written in reStructuredText (which can then be pasted into the wiki, or rendered by the pkgdb, etc)12:00
wwoodsrepo with flat files also works but then I have to manage permissions on that repo12:01
wwoodsalthough maybe we should allow people to create a [packagename].plan file in pkg CVS?12:01
jlaskawhat would using CVS give us?12:02
jlaskarather ... s/CVS/$VersionControl/12:02
wwoodspredefined heirarchy layout / ACL stuff12:02
wwoodsmakes it reeeeally simple for package maintainers to add test plans to their packages12:03
jlaskamy preference would still be wiki ... it seems like the biggest bang for buck without having to invent new process12:03
-!- JSchmitt [n=s4504kr@fedora/JSchmitt] has quit [Remote closed the connection]12:03
wwoodsfair enough12:03
jlaskathe other option is certainly valid ... but I'm just thinking about the process/perms etc we'd have to wrap around it in any formal announce12:04
wwoodsso how do we manage different versions of test plans for different package versions12:04
jlaskaand then the script to migrate the data into the wiki or some other presentation layer12:04
wwoodsthere's not going to be a formal announcement until we get the testopia problem sorted12:05
wwoodsthis is really just a stopgap 12:05
jlaskawwoods: yeah that's a good question ... at what level do we want to bind packages to test plan12:05
jlaska%{name}  %{srcname}  %{name}-%{version} etc...12:05
-!- JSchmitt [n=s4504kr@fedora/JSchmitt] has joined #fedora-meeting12:06
f13well, the simple answer is we bind fedora versions to it12:06
f13the F-9 bind plan, the F-8 bind plan, the rawhide bind plan12:06
f13builds from those branches trigger test runs from those branches.12:06
wwoodsYeah, I'd say something like: Test Plans/F10/SOURCE_PACKAGE12:06
jlaskathat's a good idea12:07
f13if we were going to do it in SCM somewhere, I'd prefer it goes with the package scm.12:07
jlaskaand likely works well with how any future mgmt tooling will stucture this stuff12:07
wwoodsand maintainers can opt to, say, have their package redirect its test plan to a different test plan12:07
wwoodsso Test Plans/F10/xulrunner could redirect to the firefox plan12:08
-!- j6k [n=j6k@f151080.upc-f.chello.nl] has joined #fedora-meeting12:08
jlaskawwoods: ooh that's good12:08
chewwoods, pong12:08
wwoodswe're re-creating the package SCM layout in the wiki. but whatever, that's fine12:09
chewwoods, an important part to improve current qa for updates would be to assure that for testing updates the whole dep tree is beeing rebuilt12:09
chewwoods, now there is atleast some checking done already.12:09
chewwoods, updates-testing report12:09
wwoodsche: see previous discussion about why we can't actually do that in any reasonable amount of time12:09
f13**with today's toolsets12:09
chewwoods, please publish the logs somewhere. i have to leave now unfortunately.12:09
chewwoods, without that there cant be proper regression testing though.12:10
-!- che [n=rkastl@redhat/che] has quit ["Verlassend"]12:10
-!- hanthana_ [n=hanthana@] has joined #fedora-meeting12:11
wwoodsokay, so, we're gonna recommend that people write test plans in the wiki. are we gonna worry about having individual pages for each test case?12:11
jlaskawwoods: how would you feel about leaving that up to the test plan author ... but providing several examples to help guide authors?12:12
-!- hanthana_ [n=hanthana@] has quit [Client Quit]12:12
jlaskahere's one way ... another way etc...12:12
-!- hanthana_ [n=hanthana@] has joined #fedora-meeting12:12
wwoodsyeah, that's fine too12:13
jlaskawwoods: would you be open to selecting a subset of components to target for the first round?12:13
jlaskatier#1 type stuff ... like yum, kernel, rpm, glibc ...12:13
wwoodsdefinitely, although a glibc test plan would be really dang hard to write12:14
jlaskanot ... joe, nedit etc...12:14
wwoodsbut some basic test plans for important components would be a really good idea12:14
jlaskamaybe some tier#1 desktop stuff ... firefox ... gnome-session ... dunno12:15
-!- ianweller_afk is now known as ianweller12:16
* jlaska thinking of the components that are most embarrasing when shipped DOA12:16
-!- sonar_logger3 [n=sglaser@dpc6744130021.direcpc.com] has joined #fedora-meeting12:16
wwoodsyeah, desktop stuff is better. also: yum12:17
wwoodsanyway, pick a couple of things and write skeletal plans12:18
-!- DemonJester [n=bpowell0@fedora/DemonJester] has quit ["leaving"]12:18
wwoodsand we'll work on getting guidelines and linkage to bodhi/pkgdb once we have played a bit12:18
wwoodsso, yeah, recommended page location: Test Plans/[dist]/[source package]12:19
wwoodsdoes the MW API catch redirects, I wonder?12:20
jlaskaI think it supports various types of includes as another option12:20
wwoodslike if you ask it for the contents of Test Plans/F10/xulrunner and that redirects to Test Plans/F10/firefox and *that* redirects to Test Plans/firefox12:20
jlaskahrmm, not sure right now12:21
-!- hanthana [n=hanthana@] has quit [No route to host]12:21
wwoodswe'll need to investigate that before we try wiring up to bodhi12:22
wwoodsanyway, we're well over time for the meeting. and lunch, for that matter.12:22
wwoodsanything else we should discuss?12:22
-!- wwoods changed the topic of #fedora-meeting to: Fedora QA Meeting | misc.12:22
jlaskakeep up with the /topic changes please ... I really enjoy that12:22
jlaskahelps when reading the notes later too12:22
wwoodsyup! I try to remember to do that12:23
wwoodsOkay, I'm going to take the silence as a "no" and end the meeting12:23
wwoodsthanks for your time, folks12:23
jlaskathanks wwoods12:23
--- Log closed Wed Jul 09 12:24:02 2008

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