15:03:27 <rjune> #startmeeting
15:03:34 <rjune> #chair adamw tk009
15:03:37 <adamw> rdieter: if you grep logs for dracut you should be able to find it, assuming i'm not misremembering entirely where i found it
15:03:45 <rjune> #topic roll call
15:03:48 <rjune> Ok, who's here?
15:04:01 * thomasj 
15:04:04 * arxs here
15:04:17 * tk009 
15:04:29 * SMParrish here
15:04:33 <rjune> adamw, I know you're around, pipe up.
15:04:33 <adamw> yo
15:05:29 <rjune> All right, thanks for coming. Without further ado, lets get started.
15:05:32 <rjune> #topic Action Item - adamw: Liaison with desktop team for feedback on
15:05:39 <rjune> adamw, you have the floor
15:05:49 <adamw> yeah, so, i screwed up
15:06:09 <rjune> congrats ;-)
15:06:15 <adamw> didn't get around to it. i have shiny graphics card drivers to screw around with! you expect me to do boring meeting action items? :)
15:06:33 <adamw> sorry. it's not hugely important, anyway, as we know several other significant dev teams want the New World Order.
15:06:41 <tk009> does the answer matter for the vote?
15:06:54 <adamw> i don't think so, but...someone may disagree
15:07:10 <tk009> I don't think so either
15:08:07 <tk009> and the gfx card issue was worth it =)
15:08:16 <tk009> I don;'t like no X
15:08:53 <tk009> I added that item the the agenda because of the vote
15:09:04 <tk009> I guess we can move on
15:09:06 <adamw> no probs, you're right to add it, i should've got to it
15:09:07 <adamw> yep
15:09:20 <arxs> yes
15:09:25 <rjune> #Topic Action Item - adamw: Confirm what bug report changes generate bugzilla mail.
15:09:47 <tk009> again related topic
15:09:49 <tk009> =)
15:10:18 <rjune> adamw, I'm assuming you didn't get here either.
15:10:33 <arxs> it's hard to say, because you can change this seeting in bz, or not?
15:10:43 <adamw> yeah, so, uh, the dog ate it
15:10:50 <rjune> LOL
15:10:58 <rjune> ok, we put that off a week too
15:11:03 <adamw> actually i was trying to test but none of my tests were doing what they were supposed to do so i had a hissy fit and gave up
15:11:04 <rjune> #Topic Semantics - Discuss and vote on the purposed triage policy.
15:11:09 <adamw> my official answer is 'what arxs said'
15:11:15 <rjune> #link https://www.redhat.com/archives/fedora-test-list/2009-August/msg00039.html
15:11:23 <rjune> ok, so this needs to be gone over
15:12:23 <rjune> On an unrelated note, chromium throws a hissy fit over https links at Red Hat. Claims that the certificate has been revoked, do any of the Red Hat guys know what's going on?
15:12:46 * comphappy is here
15:13:32 <comphappy> rjune: I just opened that link and it did not have an issue with the cert
15:13:52 <tk009> I wish mcepl was here as I know he has an opinion on this subject
15:14:10 <tk009> my own after allot of thought is to change nothing
15:14:15 <mcepl> rjune: I didn't want to vote on this issue, but when looking on your link, I have to stand and vote against #2, do #1 or #3, but I don't want to have dual regime in bugzilla
15:14:18 <mcepl> tk009: I am
15:14:22 <tk009> =)
15:14:36 <adamw> i'm in favour of #2 myself, i have to say
15:15:00 <adamw> hi comphappy
15:15:14 <adamw> are we explaining choices or just voting?
15:15:15 <arxs> me too, #2
15:15:22 <rjune> discussion right now
15:15:25 <tk009> we can do both
15:15:45 <comphappy> I am concerned that doing #3 will result in bugs that are not triaged being marked triaged
15:15:49 <SMParrish> I also could live with #2
15:16:01 <adamw> i think we should make the keyword change as it would clearly be good for some important dev teams, and i'm sympathetic to the argument that trying to convert existing bugs will screw things up and annoy people
15:16:03 <adamw> hence #2
15:16:12 <rjune> does anyone need any clarification on the three options?
15:16:15 <comphappy> I also agree with mcepl though that dual is bad
15:16:27 <mcepl> #1 or #3, against #2
15:16:44 <tk009> my issue is this in a nutshell
15:16:49 <adamw> i see mcepl's a tactical voter ;)
15:16:52 <tk009> who does this change help
15:16:52 <mcepl> (actually, I am for #1 to be honest)
15:16:57 <comphappy> I would much rather see any change like that happen inline with a release schedual
15:17:15 <adamw> ooh, that's an interesting option #4
15:17:20 <adamw> do option #2 only at a release boundary
15:17:23 <adamw> i could go with that
15:17:34 <comphappy> more like #3
15:17:48 <comphappy> but either way that would make me OK with #2
15:18:00 <adamw> it's a dual regime, but at least with a clear handover point
15:18:03 <tk009> get off the fence people =P
15:18:46 <adamw> well, what if we throw #4 into the pot: change to a keyword and don't convert old bugs, but do it at F12 release: all bugs after F12 release (so F13+) will be done with the new system
15:18:51 <adamw> i'd vote for that
15:18:57 <adamw> does it change anyone else's vote?
15:19:22 <mcepl> I can (grinding my teeth in disgust) compromise on that as well.
15:19:29 <rjune> heh
15:19:40 <comphappy> I could go with #4
15:19:44 <arxs> adamw: this is what i guess for #2 :) therefore #4
15:19:51 <tk009> I hate bending but wont hold up progress
15:20:25 <SMParrish> adamw: how will the fact the rawhide is never freezing effect this.  My understanding is that once F12 alpha comes out  bugzilla will be branched at that point
15:20:28 * mcepl sees that he is the only one with #1 and that's the position hard to sustain
15:20:52 <tk009> you are not alone mcepl
15:20:57 <comphappy> mcepl: I am with you but I dont see it as a winning battle
15:21:20 <adamw> actually, we have no majority in favour of any option atm
15:21:32 <adamw> and if comphappy is for #1 that makes it the equal leading choice :)
15:21:33 <tk009> that was y thinking as well
15:21:42 <mcepl> wohooo!!!
15:21:48 <arxs> mcepl: i think that the introduction of a new non-standard way with a new state is not got
15:22:10 <comphappy> adamw: but we are getting presure from the community to change it, more so then the internal group
15:22:12 <mcepl> OK, then I am quickly retreating to my original position ... #1 or death!
15:22:12 <adamw> arxs: ON_DEV is not new, it's just not used by everyone at present
15:22:23 <adamw> now THAT'S the fedora way ;)
15:22:28 <arxs> maybe next release someone need a ON_QA before on ON_DEV
15:22:41 <tk009> comphappy explain that please
15:22:53 <arxs> adamw: i mean new within the usage of the workflow
15:23:22 <adamw> it's not even new in that sense, if you look at the definition, that's exactly what it's supposed to be used for. some dev groups just don't want to change their practices, though.
15:23:28 <comphappy> ok, so our overall goal is to make it easy on developers to fix the bugs assigned to the components and therefor make the user experiance better
15:23:40 <comphappy> to do this we need to focus on core components
15:23:49 <adamw> i should note that on a practical basis the reason i'm against #1 is simply because we already _tried_ suggesting that to some dev groups, and they just didn't go for it.
15:23:57 <mcepl> adamw: no the Fedora way is to write a long rant on fedora-devel about how everybody else (especially Ralf Corsepius) suck!
15:23:59 <comphappy> those core components to not like our current process
15:24:29 <comphappy> and in some ways we are the wipping boys of them
15:24:34 <adamw> mcepl: ralf corsepius _does_ suck. he sent me a private email in which he opined that my moral stance is equivalent to that of a racist mass murderer. anyhoo...
15:24:38 <comphappy> we bend to them more then they bend to us
15:24:48 <arxs> adamw: right, but with #1 we have the standard way and the non-standard way, that is confusing, and it could be result in a third (4th, 5th) non-standard way
15:25:05 <adamw> true
15:25:05 * comphappy would like to get back to the topic on hand
15:25:26 <tk009> comphappy I see what you are saying
15:25:31 <mcepl> adamw: let's keep it a) on topic, b) non-personal
15:25:33 <tk009> arxs is also correct
15:25:41 * mcepl is repentent
15:25:49 <tk009> if the devs had their way...
15:25:54 <tk009> we'd do nothing
15:26:03 <tk009> sorry that isnt going to happen
15:26:06 <comphappy> tk009, not true
15:26:11 <rjune> Some of them have to apreciate the work.
15:26:13 <adamw> i don't think that's actually true. if it were we _should_ do nothing
15:26:16 <tk009> that is how i am hearing it
15:26:22 <comphappy> some of them even have internal triage groups
15:26:23 <rjune> I'm guessing the ones that have had good experiences in the past
15:26:39 <adamw> but i remember f13 saying the reason he wanted this change is some dev groups actually want the work triage does, but find the NEW/ASSIGNED system disruptive
15:26:41 <comphappy> (anaconda
15:26:43 <comphappy> )
15:27:16 <adamw> comphappy: andy is officially part of our group now, her triage process is in line with ours and we can provide extra anaconda triagers if we actually want to.
15:27:18 <rjune> adamw, have they made any suggestions as to what they would like?
15:27:35 <adamw> rjune: yes, they want the keyword system.
15:27:40 <comphappy> oh that was not a dig at anaconda at all, I was saying some groups see it as important
15:27:42 <tk009> the light footprint possible on bug reports
15:27:46 <adamw> that was the discussion at the last couple of meetings.
15:27:49 <tk009> that is what f13 said
15:27:50 <rjune> there any reason for us to not use the keyword system?
15:28:09 <adamw> tk009: by which he means the lightest footprint necessary to actually do our job, which i think is accurate; we don't want to make more noise than we _need_ to
15:28:25 <comphappy> this all comes back to why I feel we have to make a change, and the lesser of the evils is #4
15:28:35 <adamw> rjune: if we were in a hypothetical situation where we were starting from scratch and had to pick one or the other, i can't think of one
15:28:46 <adamw> rjune: the only objections appear to be related to the _transition_ rather than the system on its merits
15:28:53 <rjune> ok.
15:28:59 <adamw> (speak up if i'm wrong!)
15:29:16 <comphappy> can we take a straight up no comment vote
15:29:21 <comphappy> just to see where we are
15:29:27 <adamw> #4
15:29:30 <comphappy> #4
15:29:31 <tk009> #1
15:29:35 <arxs> #4
15:29:36 <rjune> #4
15:29:54 <adamw> mcepl?
15:30:11 <tk009> mcepl is #1 as well
15:30:15 <tk009> we know this
15:30:31 <mcepl> yes, of course
15:30:32 <tk009> so #4 has the ajority
15:30:42 <rjune> It seems to me that the discussion should focus on how to make the transition, not what to transition to.
15:31:32 <adamw> rjune: that is effectively the discussion (and the vote) - the choices in the vote are 'don't change' and then three variations on how to change to a single end result
15:31:36 <mcepl> rjune: that's what I was saying ... we should do transition not left our bugzilla in mess (take a look at bugzilla.mozilla.org how bugzilla looks after couple of significant changes without convresion)
15:32:06 <rjune> mcepl, so your only complaint is backword porting of bugs to the new system?
15:32:08 <adamw> mcepl: are you confident we could actually do a conversion reliably / accurately?
15:32:19 <rjune> adamw, I missed the last meeting.
15:32:50 <mcepl> adamw: no, and that was my biggest reason against any change
15:33:45 <mcepl> but the change without conversion is even worse
15:34:01 <comphappy> bugzilla itself does not like to see massive changes it tends to break the xmlrpc
15:34:04 <adamw> i think the conversion pain will be quite limited
15:34:13 <adamw> on a practical basis, how often do we still look at bugs from f9?
15:34:14 <comphappy> there are dates that cannot be queried because of past changes
15:34:26 <mcepl> adamw: I don't care about CLOSED bugs
15:34:47 <adamw> so if we made this change starting with f13, by the time f14 came out we'd pretty much be done
15:34:48 <mcepl> and yes, I don't care about F9 bugs
15:35:04 <adamw> in practical terms, almost no-one would be looking at bugs using the old system any more
15:35:26 <mcepl> especially in this cycle I have to admit, even N-1 Fedora gets pretty rough treatment.
15:36:46 <adamw> so, uh, i'm not sure what to do :) we have a 4-2 majority in favour of option #4, but i always like consensus, i'm not sure we should just override the minority...
15:36:48 * adamw flaps
15:37:18 <tk009> I am ok with out voted
15:37:23 <tk009> that is life
15:37:44 <mcepl> considering that I promised to shut up on this issue I said too much :)
15:37:44 <adamw> if it's any consolation you get to sit in the peanut gallery and be smug and say 'i told you so'
15:38:14 <rjune> only when things break
15:38:17 <adamw> ok, so, decision - we go ahead with option #4, with the objections of tk009 and mcepl registered
15:38:32 <tk009> that would be an agreed
15:38:48 <adamw> in practical terms, we alert the list to this choice and try not to forget about it at the end of the cycle :)
15:38:50 <mcepl> (I am from lawyers family, so i will go write my dissent, if my wimsey's call me so)
15:39:04 <adamw> if we get significant discord in response on the list, we can always reconsider
15:39:14 <comphappy> ok we need to cordentate with releng about when this transition is then right?\
15:39:26 <arxs> adamw: sounds good to mee
15:39:56 <rjune> adamw, tag it agreed then?
15:40:07 <tk009> yessir
15:40:07 <adamw> #agreed option #4 is the winner
15:40:21 <adamw> #action adamw to mail the list and explain the decision in favour of option #4, and future action
15:40:40 <adamw> comphappy: basically we should switch at the point mainstream rawhide starts getting packages destined for f13
15:40:49 <rjune> Option 4 is to Option 2 broken at a release boundary
15:40:54 <SMParrish> adamw: That happens soon
15:40:54 <rjune> specifically F12
15:40:55 <adamw> yes
15:41:19 <adamw> SMParrish: not AIUI, the actual rawhide repository on public mirrors follows f12 right up to release more or less
15:41:37 <adamw> the switcharoonie happens just shortly before release
15:41:48 <tk009> I thought about 30 days before
15:41:50 <SMParrish> Actually it doesn't anymore
15:42:06 <comphappy> can someone just get a date from releng and post it to the lits?
15:42:18 <adamw> i know who to call
15:42:21 <adamw> oxf3: help!
15:42:25 <tk009> lol
15:42:25 <adamw> Oxf13: help!
15:42:32 * adamw projects the f13 sign onto the skies
15:42:36 <rjune> LOL
15:42:38 <SMParrish> What we discussed at the recent FAD is that since rawhide will always be a moving target when F12 goes alpha bugzilla will be branched to show F12
15:42:56 <adamw> SMParrish: i'm not sure that plan has actually been implemented for this cycle
15:43:24 <adamw> hmm, oxf13 appears to be otherwise engaged
15:43:29 <Oxf13> nope, I'm here
15:43:32 <adamw> ah
15:43:33 <SMParrish> it was supposed to be.  But I admit my brain has been on vacation the past week or 2
15:43:47 <adamw> Oxf13: we need to know when exactly rawhide will stop being f12 and start being f13
15:43:55 <adamw> what's the plan on that? is it changed from previous cycles?
15:44:00 <Oxf13> No frozen rawhide was approved by FESCo, but we didn't get infrastructure done in time to enact it for F12
15:44:16 <Oxf13> therefor rawhide the path will continue to be F12 content until just before F12 is released to the public
15:44:22 <adamw> OK
15:44:23 <adamw> thanks!
15:44:33 <Oxf13> the exact date of the changeover depends on when we reach GOLD status with F12
15:44:40 <Oxf13> and what the mirrors will allow
15:44:44 <SMParrish> Thanks Oxf13, I knew my brain was tired
15:44:46 <adamw> yep.
15:45:05 <comphappy> ok anything else on the adgenda?
15:45:07 <adamw> ok then, i think we have that covered
15:45:23 <rjune> Moving on then
15:45:26 <rjune> #Topic xmms - Discuss the request for triage help.
15:45:34 <rjune> #link https://www.redhat.com/archives/fedora-devel-list/2009-August/msg00490.html
15:45:41 <tk009> while I know this was not a direct request to us
15:45:49 <tk009> I thought it was worth bringing up
15:46:04 <tk009> I had a look and saw the auto closed
15:46:09 <adamw> yeah, it triggered my alarms too
15:46:18 <tk009> I don't use xmms anymore tho
15:46:32 <adamw> me either
15:46:45 <tk009> does anyone?
15:46:53 <arxs> is this the normal way? that if a component is orphaning, all bugs gets auto closed?
15:47:14 <tk009> no it was EOL that closed them
15:47:18 <arxs> tk009: me also either
15:47:22 <tk009> not orphan
15:48:43 <tk009> well they are requesting help in triage, do we try and help
15:48:50 <comphappy> I dont think this concerns us, any other topics?
15:48:54 <tk009> or is this a dead package that just doesnt know it
15:49:19 <tk009> if it says triage I think it does comphappy
15:49:29 <adamw> i think it's pretty much a dead package walking...
15:49:31 <adamw> who's the xmms maintainer?
15:50:03 <tk009> I don't know
15:50:05 <arxs> pfj
15:50:12 <comphappy> tk009: it is looking for a developer unless we are not taking on the role of fixing the bugs I dont think it really does
15:50:25 <comphappy> *are
15:50:55 <tk009> I thought that was for -sid
15:51:20 <tk009> well doesnt look like anyone uses it anyway here
15:51:32 <tk009> so not muc hwe can do unless someone wants to dive in
15:51:46 <rjune> Ugh, not there.
15:51:52 <tk009> moveing on I guess
15:52:06 <rjune> #Topic Creating the agenda and use of the meeting agenda list.
15:52:21 <tk009> I wanted to talk about the sop
15:52:29 <tk009> and using the agenda list
15:52:45 <tk009> on the agenda list
15:52:51 <tk009> its not getting used at all
15:52:54 <arxs> tk009: is the sop in the wiki?
15:53:07 <tk009> yet it would make getting the agenda ready for the eeting much easier
15:53:16 <tk009> it is not arxs
15:53:28 <adamw> i think only tk009 and rjune usually get involved in doing the agenda, right?
15:53:37 <rjune> as far as I know.
15:53:39 <tk009> arxs wants a hand in htat
15:53:39 <adamw> i haven't for a bit (except reviewing the draft agenda you guys send me)
15:53:55 <adamw> brb, call of nature
15:54:13 <arxs> and also in the recap
15:54:17 <tk009> I am fine with doing it but I worry I am missing stuff others want on the agenda
15:54:25 <mcepl> what's sop?
15:54:34 <rjune> Standard Operating Procedure
15:54:40 <tk009> standard operating proceedure
15:54:41 <arxs> the "needs to be written" on :)
15:54:48 <tk009> yes that one
15:54:50 <tk009> =)
15:55:06 <tk009> ok will little time left make that an action item for me
15:55:14 <arxs> only 5 minutes left in time
15:55:24 <tk009> a draft agenda sop
15:55:30 <tk009> or meetin/agenda
15:56:08 <arxs> #action tk009 create a draft sop for the meeting/agenda list
15:56:23 <rjune> way to take charge.
15:56:37 <tk009> =)
15:56:48 <rjune> anything else about that?
15:56:55 <arxs> oops. i can't #action... :/
15:56:56 <rjune> really you have most experience with it.
15:57:02 <rjune> #chair arxs
15:57:03 <arxs> can one chair please do it?
15:57:07 <arxs> #action tk009 create a draft sop for the meeting/agenda list
15:57:13 <arxs> rjune: thanks :)
15:57:45 <tk009> I think that is it
15:57:48 <rjune> #topic open forum
15:58:29 <arxs> well, i'm back from holidays (7 days), did i miss something importent?
15:58:31 <tk009> nothing for me on open
15:58:39 <arxs> beside of slip of alpha
15:58:50 <tk009> no not really
15:58:52 <mcepl> I have one question ... I was tlaking about it with adamw, he didn't think it is importnat, but I would like us to at least think about it.
15:59:01 <tk009> kk
15:59:11 <mcepl> that is CLOSED/UPSTREAM ... three years I am doing this, I hate the way we do it
15:59:24 <tk009> yes I saw your comments on that
15:59:28 <tk009> and agree
15:59:43 <arxs> mcepl: where are the comments?
15:59:50 <mcepl> when we push the bug upstream it just shouldn't IMHO be CLOSED
15:59:54 <tk009> they were in IRC
15:59:59 <mcepl> arxs: #fedora-bugzappers and PM
16:00:21 <mcepl> OTOH it is more work for us (because we have to retest all upstreamed bugs with new releases)
16:01:02 <tk009> should we add this to next weeks meeting?
16:01:14 <arxs> yes!
16:02:03 <tk009> I need to review the policy on upstream I don't know it as well as I should
16:02:05 <adamw> yeah, throw it on next week's agenda
16:02:09 <adamw> we need moer time than we have now
16:02:18 <tk009> we are over
16:02:27 <tk009> that should be a wrap
16:02:44 <arxs> k, nothing more from me
16:02:52 <tk009> my dogs wants out anyway
16:02:53 <mcepl> adamw: would you mind if I put our discussion somewhere on the web?
16:03:33 <adamw> mcepl: please, go ahead
16:04:27 <rjune> #endmeeting