=================================== #fedora-meeting: FESCO (2010-03-09) =================================== Meeting started by nirik at 20:00:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-03-09/fesco.2010-03-09-20.00.log.html . Meeting summary --------------- * init process (nirik, 20:00:17) * #314 Wordpress bundles libraries (nirik, 20:03:59) * AGREED: wordpress should unbundle libraries that are upstream identical. Can bundle 3 heavily modified php files. (nirik, 20:11:32) * Daylight savings time. Move meeting time or keep the same? (nirik, 20:11:54) * proposed: shift with DST starting next week (nirik, 20:18:41) * AGREED: Meeting will change to 19UTC starting next week. (nirik, 20:19:36) * #349 comps in git - notting (nirik, 20:19:48) * Comps is moving to git. See ticket or mailing lists posts for more. (nirik, 20:26:34) * Fedora Engineering Services Tickets/Updates. (nirik, 20:27:10) * FES #2 SIGs roundup and pinging - jds2001 (nirik, 20:27:25) * FES #5 Fix broken dependencies - itmarjp (nirik, 20:28:46) * FES #6 Fix packages that fail to build from source - bruno (nirik, 20:29:11) * FES #7 spec cleanup task: fix the need for perl (etc) in scriptlets - mmcgrath (nirik, 20:29:37) * LINK: https://fedorahosted.org/fedora-engineering-services/report/6 (nirik, 20:30:09) * FES #8 Document Fedora as android devel platform - stickster (nirik, 20:30:39) * unassigned FES tickets (nirik, 20:31:10) * Updates Discussion (nirik, 20:38:27) * LINK: https://fedoraproject.org/wiki/UpdatePolicy(draft) (nirik, 20:57:23) * will work on nottings proposal over the next week and revisit next week. (nirik, 21:31:19) * AutoQA (nirik, 21:31:28) * Open Floor (nirik, 21:35:32) * LINK: https://fedoraproject.org/wiki/Board/SuccessionPlanning (jwb, 21:42:32) * ACTION: skvidal to write up proposal for FESCO member removal (mjg59, 21:46:42) Meeting ended at 21:46:42 UTC. Action Items ------------ * skvidal to write up proposal for FESCO member removal Action Items, by person ----------------------- * skvidal * skvidal to write up proposal for FESCO member removal * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * nirik (181) * Kevin_Kofler (162) * mjg59 (91) * skvidal (83) * cwickert (63) * dgilmore (61) * pjones- (43) * notting (42) * ajax (38) * Oxf13 (36) * jwb (19) * abadger1999 (18) * adamw (17) * jlaska (13) * gholms (10) * drago01 (9) * zodbot (7) * mmcgrath (6) * cjb (5) * ricky (3) * lmacken (3) * Rathann|lappy (2) * thomasj (1) * thm (1) * geppetto (1) * pjones (0) 20:00:01 <nirik> #startmeeting FESCO (2010-03-09) 20:00:02 <zodbot> Meeting started Tue Mar 9 20:00:01 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:04 <nirik> #meetingname fesco 20:00:05 <mjg59> Hi 20:00:06 <zodbot> The meeting name has been set to 'fesco' 20:00:11 <nirik> #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones cwickert mjg59 20:00:12 <zodbot> Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 nirik notting pjones skvidal 20:00:16 * skvidal is here 20:00:17 <nirik> #topic init process 20:00:32 * cwickert is in the house... 20:00:33 <Kevin_Kofler> Present. 20:00:47 <ajax> i am not a crook 20:01:00 <nirik> NOTE: I may have to leave before the end of the meeting... I have to pick up a dog from the vet. Hopefully it will be after the meeting is over tho. 20:01:24 * skvidal would like to note - if this stops being a fesco meeting and starts to be a free for all 20:01:29 <skvidal> I'm going to make the channel voice-only 20:01:47 <skvidal> and we'll turn people on and off 20:01:50 <nirik> skvidal: hopefully it will not be needed. 20:01:52 <mjg59> Guest97970: Probably want to identify... 20:01:55 * notting is here 20:01:55 <Kevin_Kofler> Hooray for democracy. :-/ 20:01:56 <skvidal> nirik: I hope so, too 20:02:03 <mmcgrath> skvidal: no it is you that is wrong! 20:02:21 <cwickert> skvidal, please don#t 20:02:23 <nirik> lets all relax and rememeber we are all here to make Fedora better. 20:02:29 <skvidal> cwickert: I said - if it becomes a problem. 20:02:39 * thomasj lurking 20:02:59 <nirik> ok, shall we get started? who are we missing? 20:03:01 <nirik> dgilmore: ? 20:03:30 <nirik> pjones seems to be having connection issues. ;( 20:03:39 <skvidal> I just pinged dgilmore 20:03:45 <pjones-> yep. 20:03:56 <nirik> cool. I guess lets start in... 20:03:57 * dgilmore is here 20:03:59 <nirik> #topic #314 Wordpress bundles libraries 20:04:00 <skvidal> there he is 20:04:02 <nirik> .fesco 314 20:04:03 <zodbot> nirik: #314 (Wordpress bundles libraries) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/314 20:04:11 <nirik> this is a issue thats been on the back burner for a while... 20:04:19 <nirik> but packaging I think has looked at it now... 20:04:59 <nirik> so, we need to decide on the 3 files that are modified from other places... are they bundling? should we allow or disallow it? 20:05:18 <nirik> or should we see if we can task some members with looking more closely for us? 20:05:48 <mjg59> If they're more than trivially modified, I think it's outside the realm of a packager's job to handle it 20:05:56 <notting> nirik: is there a link to the work packaging has done here? 20:05:57 <Kevin_Kofler> Likewise. 20:05:59 <notting> (it's not in the ticket) 20:06:02 <gholms> Maybe a FES ticket? 20:06:14 <Kevin_Kofler> I think we should just let the modified ones pass. 20:06:16 <nirik> I thought the last comment had their info... 20:06:19 * nirik looks again. 20:06:21 <mjg59> Obviously it'd be preferable if there were no deviation from upstream, but where code has legitimately forked, it's not obvious what the "right" thing to do is 20:06:31 <Kevin_Kofler> Yeah. 20:06:35 <cwickert> i have been talking to a wordpress developer at cebit. he said he sees the problem, but they have no intentions do change it. 20:06:40 <pjones-> I think the modified ones are simply going to be too difficult to handle reasonably 20:06:49 <Kevin_Kofler> If we "fix" it yourself, we'll be forking Wordpress. 20:06:56 <pjones-> the unmodified ones, however, stand in the face of any reasonable technical position. 20:06:59 <mjg59> So I'm happy with requring that the upstream-identical ones are broken out and that the others ermain bundled 20:07:02 <Kevin_Kofler> It's kinda hard to argue that we're forking Wordpress because forking is bad. ;-) 20:07:14 <Kevin_Kofler> s/yourself/ourselves/ 20:07:48 <cwickert> I'm afraid we might get in trouble from the security pov. it will slow down security updates 20:07:53 <ajax> as usual, i think the guideline here is properly "minimal divergence", not "no divergence" 20:08:00 <pjones-> right 20:08:09 <nirik> well, the first problem is that the current maintainer doesn't have interest in doing that work I don't think... 20:08:29 <nirik> but I guess we should ask them to, or find a maintainer who is willing to, or drop the package. 20:09:28 <nirik> proposed: upstream-identical parts must be unbundled/patched. 3 heavily modified files can remain as shipped by upstream. 20:09:45 <mjg59> +1 20:10:02 * notting is +1 to that proposal 20:10:18 <skvidal> +1 20:10:23 <Kevin_Kofler> +1 20:10:35 <nirik> +1 here as well. 20:10:38 <ajax> sounds right to me. +1, although i'd like some way of catching whether wp later updates the "upstream-identical" parts. 20:10:50 <nirik> ajax: automated you mean? or ? 20:11:15 <ajax> automated would be nice, although "patch -F0" counts as automated for this purpose 20:11:25 <pjones-> +1 20:11:32 <nirik> #agreed wordpress should unbundle libraries that are upstream identical. Can bundle 3 heavily modified php files. 20:11:49 <nirik> ok, on to new business... 20:11:54 <nirik> #topic Daylight savings time. Move meeting time or keep the same? 20:12:02 <nirik> DST starts in the us next weekend. 20:12:10 <mjg59> I have a hard cut off at 6PM eastern time 20:12:11 <nirik> Do we move the meeting time? or keep it at this same time UTC? 20:12:36 * nirik doesn't care. +-1hour is fine here. 20:12:38 <mjg59> Which would be consistent with a 2 hour meeting starting an hour later here 20:13:03 <mjg59> Is there anyone from the southern hemisphere/a region which doesn't observe DST? 20:13:16 <cwickert> just for the record: i disagree 20:13:29 <skvidal> cwickert: with daylight savings time? 20:13:34 <nirik> cwickert: huh? moving or not moving? 20:13:38 <mjg59> cwickert: That was an or option :) 20:13:39 <cwickert> skvidal, sorry, unbundeling wordpress 20:13:48 <mjg59> Ah, ok 20:13:49 <skvidal> cwickert: oh ok 20:13:52 <nirik> ah. sorry if I moved on too soo. ;( 20:13:53 <dgilmore> mjg59: i think we have a couple of non DST people 20:13:55 <notting> i have a soft cutoff at 5PM eastern for at least a couple of weeks 20:13:56 * cwickert was late, sorry 20:14:09 <Kevin_Kofler> Re DST, I propose we move on the European DST switchover. :-) 20:14:19 <nirik> Kevin_Kofler: :) when is that? 20:14:21 <mjg59> Kevin_Kofler: Are you able to make an hour earlier until we resync? 20:14:43 <dgilmore> I think we should stick with UTC 20:14:52 <Kevin_Kofler> mjg59: Yes, it's just annoying, but I can deal with it. 20:14:57 <mjg59> I'm easy either way 20:15:05 <pjones-> how long is there in between them? 20:15:09 <mjg59> But sticking with UTC means that the majority of people will be doing this an hour later during summer 20:15:14 <skvidal> pjones-: 3 weeks, iirc 20:15:23 <dgilmore> pjones-: i think 3 weeks at the start and 1 at the end 20:15:29 <cwickert> European DST switch is 2010-03-28 20:15:31 <ajax> no preference. 20:15:34 <Kevin_Kofler> Last Sunday in March. 20:15:45 <cwickert> at 3:00 UTC 20:15:49 <mjg59> Ok, so there'd be two weeks of difference 20:16:01 <nirik> so does anyone actually have a preference? 20:16:03 <pjones-> I could deal with either moving it or not; I'd rather keep in line with EST5EDT 20:16:13 <mjg59> We can either retain UTC, change next week or change in three weeks 20:16:20 <mjg59> I don't see any benefit in retaining UTC 20:16:32 <mjg59> Unless there's anyone in a non-DST region who can't change 20:16:38 <pjones-> right; seems like the right thing to do is to change, and the question is when 20:16:54 <mjg59> I can handle two weeks being an hour later 20:16:59 <mjg59> notting would prefer not to 20:17:17 <mjg59> So does anyone have an actual hard cutoff during the next two weeks? 20:17:31 <notting> wel, it just means i might have to bail early the next two weeks 20:17:33 <Kevin_Kofler> I hate DST and I'd love to retain UTC just for the principle, but in practice it'd probably just be an annoyance to have the meeting at 10 PM local time (9 PM is already late), so I think we should move, whether in 1 week or in 3 weeks is a minor issue. 20:17:39 <notting> i should be ok after that 20:18:12 <mjg59> Ok. How about changing next week? 20:18:17 <mjg59> Do we want to vote on that? 20:18:19 <nirik> WFM 20:18:41 <nirik> #info proposed: shift with DST starting next week 20:18:41 <cwickert> mjg59, no problem for me 20:18:49 <mjg59> +1 20:18:50 <skvidal> +1 20:18:52 <pjones-> +1 20:19:02 <nirik> +1, fine with me. So that makes it 19 or 21utc? 20:19:11 <Kevin_Kofler> 19 20:19:17 <dgilmore> sure +1 20:19:19 <ajax> +1 20:19:27 <cwickert> +1 20:19:30 <Kevin_Kofler> +1, fine with me. 20:19:36 <nirik> #agreed Meeting will change to 19UTC starting next week. 20:19:38 <notting> +1 20:19:48 <nirik> #topic #349 comps in git - notting 20:19:53 <cwickert> +1 20:20:00 <nirik> notting: anything we should do here? or this is informational? 20:20:01 * cwickert loves git 20:20:16 <notting> i'm mainly making sure this isn't going to upset anyone. 20:20:21 <nirik> .fesco 349 20:20:26 <Oxf13> not that it matters, but releng is in approval of this change. 20:20:27 <zodbot> nirik: #349 (comps in git) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/349 20:20:31 <Kevin_Kofler> It's upsetting me for sure, I hate git. ;-) 20:20:41 * nirik is all for it. Are you importing history as well I take it? 20:20:42 <cwickert> Kevin_Kofler, you are kidding me 20:20:46 <ajax> "the problem space is that cvs sucks". yes yes yes. 20:21:00 <dgilmore> +1 for comps in git 20:21:02 <ajax> +1 20:21:11 <notting> nirik: yes, although probably not anything more complex than git-cvsimport 20:21:21 <Kevin_Kofler> Why can't this wait for everything moving to git? 20:21:33 <ajax> it can. does it need to? 20:21:40 <Kevin_Kofler> (Not that I like that idea at all, but it's basically decided that that's going to happen, so…) 20:21:57 <Kevin_Kofler> (the idea of everything moving to git) 20:21:58 <ajax> what would be improved by waiting? 20:21:58 <Oxf13> Kevin_Kofler: that hasn't been decided at all 20:22:04 <notting> Kevin_Kofler: the only reason it's in with packages is because at the time there *was* no other fedora SCM. spin-kickstarts is already in git 20:22:19 <cwickert> as well as many other things 20:22:20 <Oxf13> Kevin_Kofler: comps wasn't necessarily tied to the package source control, it's more like our other upstream stuff which has moved to git 20:22:51 <pjones-> yeah; it's really that the package's upstream is moving. 20:22:52 <abadger1999> notting: Are we controlling who edits comps? 20:23:04 <abadger1999> (ie -- not the entirety of packager group) 20:23:15 <notting> abadger1999: not currently. 20:23:44 <nirik> ok, is there any other action/discussion here? or shall we move on? 20:23:55 <Kevin_Kofler> What concrete benefits will this change give, other than not being CVS? 20:24:14 <Oxf13> not being CVS is enough for me. 20:24:18 <Kevin_Kofler> I don't see how CVS is not working for something like comps. 20:24:27 <pjones-> it means we're treating it like we treat most other packages, which is good. 20:24:33 <Kevin_Kofler> Even things like atomic commits are useless for comps. 20:24:40 <nirik> I think it should give more visibility to it... 20:24:41 <pjones-> o_O 20:24:46 <cwickert> Kevin_Kofler, comps is very fragile for two people working on it at the same time. git will help us 20:24:49 <nirik> many people don't realize where it is in cvs these days. 20:24:49 <Oxf13> Kevin_Kofler: We consider CVS to be deprecated, ergo we're moving things off of CVS as we can 20:25:00 <pjones-> I don't think that's true. I've certainly backed out changes in comps before. 20:25:09 <mjg59> If it's going to move, I don't see any benefit in delaying the move 20:25:54 * nirik notes 9min left on the 15min timer. 20:26:02 <Kevin_Kofler> Then go ahead with it, it's not like this change is going to Break Fedora like some of the other proposals being floated. ;-) 20:26:04 <skvidal> yah - I'd almost go so far as to wonder why comps isn't in the upstream anaconda or even yum git repos 20:26:19 <Kevin_Kofler> I don't see the benefits, but it's not going to kill us either. 20:26:21 <skvidal> and grabbed from there per release 20:26:27 <Oxf13> skvidal: because we don't want @packagers having commit access to upstream yum or anaconda 20:26:34 <nirik> #info Comps is moving to git. See ticket or mailing lists posts for more. 20:26:58 <skvidal> nirik: thanks 20:27:00 <nirik> ok, I would like to do the FES status updates next... saving the updates thing for last... since it's likely to suck up a lot of time. 20:27:10 <nirik> #topic Fedora Engineering Services Tickets/Updates. 20:27:25 <nirik> #topic FES #2 SIGs roundup and pinging - jds2001 20:27:33 <nirik> I don't think jds2001 is around... 20:27:45 <nirik> I think we might need some more folks working on that ticket... spread out the contacting. 20:28:04 <nirik> mmcgrath: have you had more folks sign up of late? 20:28:27 <mmcgrath> I've had two new signups that have gotten tickets, Bruno and itamarjp 20:28:46 <nirik> #topic FES #5 Fix broken dependencies - itmarjp 20:29:00 <nirik> yeah, also in progress there... 20:29:08 <nirik> and brunos: 20:29:11 <nirik> #topic FES #6 Fix packages that fail to build from source - bruno 20:29:29 <nirik> We might also need more people working on those/dividing it into parts. 20:29:37 <nirik> #topic FES #7 spec cleanup task: fix the need for perl (etc) in scriptlets - mmcgrath 20:29:45 <nirik> mmcgrath: how's ticket 7 coming? 20:29:59 <mmcgrath> nirik: it's going ok, it's on my list for this week. 20:30:01 <cwickert> nirik, you have full links to these tickets? 20:30:07 <nirik> cwickert: oh yeah, sorry... 20:30:09 <nirik> https://fedorahosted.org/fedora-engineering-services/report/6 20:30:23 <nirik> that link should have all the tickets. 20:30:36 <nirik> one more active ticket is: 20:30:39 <nirik> #topic FES #8 Document Fedora as android devel platform - stickster 20:30:50 <nirik> who updated the ticket with some progress/info... he's working on it. 20:30:58 <Kevin_Kofler> You've skipped from #2 to #5, what about #4? 20:31:03 <nirik> we also have unassigned tickets: 20:31:10 <nirik> #topic unassigned FES tickets 20:31:15 <nirik> #4 tool idea: script to evaluate buildroot poisoning #9 Find a way to deterin active Fedora contributors via FAS scraping 20:31:21 <nirik> ack. paste fail 20:31:30 <nirik> #9 Find a way to deterin active Fedora contributors via FAS scraping 20:31:42 <nirik> Kevin_Kofler: 4 is not yet assigned. 20:31:50 <Kevin_Kofler> I posted my brute force script to #4 as promised last week. 20:31:55 <Kevin_Kofler> Nothing happened since. 20:32:11 <mmcgrath> nirik: number 9 is actually an infrastructure ticket, I'll move it. 20:32:15 <Kevin_Kofler> I think a proper solution would need to be implemented on the Koji server side, using SQL queries. 20:32:20 <nirik> mmcgrath: ah, ok. was wondering about that one. 20:32:25 <nirik> Kevin_Kofler: cool. Thanks. 20:32:53 <nirik> perhaps mbonnet or one of the koji guys could look at it... 20:33:15 <Kevin_Kofler> Because my script basically does a database query in a code loop. 20:33:22 <Kevin_Kofler> This is of course very inefficient. 20:33:32 <Kevin_Kofler> Especially with a roundtrip to Koji at every iteration. 20:33:50 <pjones-> sounds like time to re-write the database query. 20:33:52 <nirik> ok, anyone have anything on FES? tickets we should add? updates to existing ones? comments on if it's helping us at all? favorate colors? 20:33:54 <Kevin_Kofler> Multicalls might speed it up, but it'd still be a software query. 20:34:19 <Kevin_Kofler> pjones-: s/re-// 20:34:33 <pjones-> Kevin_Kofler: fair enough 20:34:49 <Kevin_Kofler> What I mean is, my code does the equivalent of a query, but by looping in software. 20:34:49 <ajax> i have some further ticket ideas. hopefully i'll find time this week to get them written down. 20:35:18 <Kevin_Kofler> And at the client end, even. 20:35:21 <ricky> Doesn't koji have usernames stored in its db? 20:35:29 <ricky> It might be easier to go off of those if it does 20:35:39 <nirik> ajax: excellent. 20:35:56 <dgilmore> ricky: it does 20:36:06 <nirik> mmcgrath: is there anything further we can do for FES right now? 20:36:08 <dgilmore> the koji usernames come from the user cert 20:36:08 <Oxf13> what does "buildroot poisoning" mean? 20:36:09 <Kevin_Kofler> ricky: I think you have been confused by the bas paste. 20:36:11 <mmcgrath> Nothing at the moment 20:36:19 <Oxf13> I have some code I already used to detect certain things used in buildroots 20:36:20 <Kevin_Kofler> *bad paste 20:36:27 <Kevin_Kofler> The FAS scraping part is actually from #9. 20:36:40 <ricky> Oh, never mind then 20:36:47 <Kevin_Kofler> #4 is: tool idea: script to evaluate buildroot poisoning 20:36:47 <nirik> Oxf13: basically a bad build (for whatever reason you think it is bad) thats used in building other builds, that in turn build others, etc. 20:37:03 <Kevin_Kofler> #9 is: Find a way to deterin active Fedora contributors via FAS scraping 20:37:08 <Oxf13> ah, I can somewhat detect the first part, but the recursion would be a bit more difficult 20:37:11 <Kevin_Kofler> where "deterin" presumably means "determine". 20:37:22 <mmcgrath> Kevin_Kofler: I just moved that one to FAS, it was opened in the wrong trac instance anwyay. 20:37:38 <nirik> ok, shall we move along then? 20:37:41 <Kevin_Kofler> nirik: The code I posted also doesn't handle the recursive part. 20:37:54 <Kevin_Kofler> Doing it recursively with my code is not going to scale at all. 20:37:55 <nirik> Kevin_Kofler: ah, good to know... but it is something to start from. ;) 20:38:15 <Kevin_Kofler> With a query to do the equivalent of my code, it might actually be possible to handle the recursive stuff in finite time. ;-) 20:38:27 <nirik> #topic Updates Discussion 20:38:44 <nirik> ok, I would like to make a few remarks here to start with. 20:39:01 <nirik> First, per our rules we have 15min, and have to vote to continue. 20:39:29 <nirik> I would remind everyone that we all here want to improve Fedora. Please keep that in mind even if you don't agree with the HOW. 20:39:31 <Kevin_Kofler> I think we should defer all this for more feedback and a more finalized proposal from QA. 20:39:42 <Kevin_Kofler> This is coming on too short a notice. 20:39:48 <pjones-> o_O 20:39:49 <nirik> there are a bunch of proposals now. 20:39:53 <Kevin_Kofler> And QA says their proposal is incomplete due to the deadline. 20:39:58 <nirik> abadger1999 has added them to: https://fedoraproject.org/wiki/UpdatePolicy(draft) 20:40:07 <Kevin_Kofler> Well, probably "complete", but not polished. 20:40:18 <nirik> also, we were going to get a 'vision' or something from the Board, and they have not yet that I know of communicated that to us. 20:40:31 <jwb> we haven't. discussion has sort of stalled 20:40:35 <jwb> - for the Board 20:40:40 <skvidal> jwb: shocking 20:40:43 <nirik> that said, perhaps we could look at what we have so far and see if there is anything we can provide feedback on or any proposals we like better than others. 20:40:54 <abadger1999> +1 to looking. 20:41:09 <mjg59> It's clear that the idea of requiring +3 karma before migration is heavily unpopular 20:41:12 <notting> well, i thought there were two issues. the board was going to define a policy on the general policy for what updates people do. which is orthogonal to criteria for getting updates pushed. 20:41:15 <skvidal> a lot of mjg59's + most of kparals + a fair bit of nottings == win 20:41:24 <skvidal> mjg59: unpopular among a vocal minority afaict 20:41:26 <Oxf13> I would appreciate fesco looking at the proposals and giving an idea of what is liked and disliked 20:41:41 <Oxf13> even if it's not unanimous liking / disliking 20:41:44 <mjg59> skvidal: It's not the intention to prevent some packages from ever being updated 20:41:47 <nirik> personally I for the most part like nottings the best. 20:41:48 <abadger1999> Oxf13: +1 20:41:51 <cwickert> mjg59, out of 300 updates i pushed only one ever reached +3. you think your proposal is realistic? 20:41:53 <skvidal> mjg59: agreed 20:42:00 <nirik> but I note that it wouldn't have done anything for dnssec-conf. 20:42:04 <Kevin_Kofler> <skvidal> mjg59: unpopular among a vocal minority afaict 20:42:06 <Kevin_Kofler> Nonsense. 20:42:17 <skvidal> cwickert: I think with a requirement of karam and more tools it gets easier and more required 20:42:23 <Kevin_Kofler> It's way too easy to write off the people you don't agree with as a "vocal minority". 20:42:24 <notting> Oxf13: well, i suppose telling you i like my proposal isn't saying much. 20:42:29 <pjones-> cwickert: one does have to wonder if that's due to having no such requirement. 20:42:32 <cwickert> skvidal, but the tools nbeed to be in place first 20:42:37 <nirik> Can we all agree with: We would like Stable Fedora releases to be more stable ? 20:42:38 <Kevin_Kofler> Many packages right now are not getting any karma, ever. 20:42:41 <Kevin_Kofler> Or at most +1. 20:42:41 <skvidal> cwickert: till's tool is handy 20:42:44 <abadger1999> One thing about notting's I would rather restrict it to critpath but enlarge critpath if need be. 20:42:46 <dgilmore> mjg59: i think that the idea of 3 +1 is unpopular because people have chosen to ignore it 20:42:48 <skvidal> nirik: +1 20:42:54 <Kevin_Kofler> karma +3 is a joke. 20:43:04 <abadger1999> nirik: Definition of stable. 20:43:04 <dgilmore> mjg59: and that once implemented and in use it will be accepted 20:43:07 <Kevin_Kofler> And it's going to annoy our most valuable contributors the most. 20:43:11 <mjg59> Kevin_Kofler: At the point where people don't get updates unless there's positive karma, I expect that things will improve 20:43:12 <cwickert> skvidal, but as long as karma ls limited to FAS acount holders it's not that useful 20:43:13 <Kevin_Kofler> (the ones with the most packages) 20:43:14 <abadger1999> nirik: Please. :-) 20:43:27 <Kevin_Kofler> (who are the most likely to also maintain niche packages where karma +3 is impossible) 20:43:30 <mjg59> The risk is when we have packages where 3 votes is a substantial proportion of the users 20:43:31 <dgilmore> nirik: +1 I agree we need to make the stable release more stable 20:43:45 <skvidal> mjg59: which, imo, makes me wonder why we're shipping those pkgs at all. 20:43:57 <Kevin_Kofler> Plus, the numeric karma is highly flawed. 20:43:57 <nirik> abadger1999: nitpicker. ;) "Less regressions for end users" ? 20:43:58 <mjg59> skvidal: It's not unreasonable 20:44:03 <Kevin_Kofler> It should be abolished, not made mandatory. 20:44:06 <dgilmore> mjg59: if there is enough interest/bugs filed etc then it wont be much of a ask 20:44:06 <skvidal> mjg59: to wonder that? or to ship them? 20:44:10 <Kevin_Kofler> "<nirik> Can we all agree with: We would like Stable Fedora releases to be more stable ?" → No. 20:44:11 <mjg59> skvidal: Either 20:44:14 <skvidal> mjg59: :) 20:44:15 <Rathann|lappy> mjg59: on what basis do you say that things will improve if lack of karma blocks updates? 20:44:15 <Kevin_Kofler> They're already stable. 20:44:20 <Kevin_Kofler> They don't need to be any more stable. 20:44:24 <Kevin_Kofler> Things are working fine. 20:44:26 <nirik> Kevin_Kofler: really? 20:44:34 <Kevin_Kofler> I don't see a need for added bureaucracy at all. 20:44:41 <cwickert> nirik, what is "more stable". if it is "less regressions", i agree, if it's "forbid all updates", I disagree because we might loose something that mekes Fedora unique 20:44:43 <Kevin_Kofler> It'll just lose us some valuable contributors. 20:44:46 <pjones-> Kevin_Kofler: okay, so the thing is, I think all of the rest of us disagree with everything you just said. 20:44:50 <nirik> Kevin_Kofler: ok, so can we simply add your -1 to any changes to current update policy? 20:44:56 <adamw> jlaska and myself feel that Bodhi is not currently a robust enough system to rely on a specific numeric vote for all updates 20:45:00 <abadger1999> nirik: Good definition. Just wantto be clear :-) 20:45:08 <notting> Kevin_Kofler: by claiming that 'things are working fine', *you* are now writing off the people you don't agree with. 20:45:09 <Kevin_Kofler> I'm sure mschwendt is not the only one who is considering leaving over a too restrictive update policy! 20:45:15 <adamw> we can't rely strongly enough on what '+3' actually means for any given update for it to be a sane criterion for accepting or not accepting it 20:45:15 <mjg59> Kevin_Kofler: This is in the week where someone described how the KDE 4.4 update broke their desktop due to various untested edge-cases? 20:45:23 <Kevin_Kofler> notting: No, I'm making a statement of fact. 20:45:29 <notting> *giggle* 20:45:30 <cwickert> I know there are people that will leave Fedora if we decide a policy that forbids major updates. both users and contributors 20:45:42 <skvidal> cwickert: people threatening to leave should leave 20:45:48 <skvidal> orphan your packages and go 20:45:52 <ajax> cwickert: and how many would we gain? 20:45:55 <Kevin_Kofler> nirik: I wish people would also consider WHY I'm saying these things, not just accept that I'll vote -1 and ignore me. 20:45:57 <skvidal> I'll be glad to clean up that mess 20:45:59 <adamw> none of the current proposals has anything to say regarding what kinds of updates can be submitted, so I don't see why it's under discussion. 20:46:17 <pjones-> Kevin_Kofler: we have considered why you're saying such things, and we simply find that your "facts" are completely out of line with reality. 20:46:29 <Kevin_Kofler> FYI, this "<cwickert> mjg59, out of 300 updates i pushed only one ever reached +3. you think your proposal is realistic?" is also my experience. 20:46:32 <mjg59> Kevin_Kofler: The status quo causes people to lose the ability to get work done. This is a significant problem for us. 20:46:36 <Kevin_Kofler> And the one of several of the high-volume maintainers. 20:46:37 <nirik> Kevin_Kofler: I would love to see your point of view, but I just don't. Why would you not want more testing? 20:46:43 <cjb> Kevin_Kofler: I've got an idea -- you could post >100 mails to a devel@ thread describing your position. 20:46:47 <cjb> oh. I think you did that already. 20:47:01 <dgilmore> Kevin_Kofler: have you considered how disruptive major kde upgrades are 20:47:02 <skvidal> cjb: please 20:47:05 <Oxf13> if I might interrupt. It would be worthwhile info to know if the majority of FESCo feels our updates are "stable" enough, or if there is room for improvement. 20:47:05 <Kevin_Kofler> nirik: Because it's not needed? Because it will lead to some important fixes not getting to users fast enough? 20:47:05 <mjg59> cjb: Let's try to stay productive 20:47:08 <cwickert> skvidal, it's not about me and it's not about threatening somebody. I think it's fair to say: If fedora is no longer leading edge, there is no reason for me to use Fedora or to contribute 20:47:10 <cjb> (sorry.) 20:47:19 <dgilmore> Kevin_Kofler: everytime you do it i need to walk my mum though how to do things 20:47:20 <skvidal> cwickert: then by all means 20:47:28 <Kevin_Kofler> I also have a hard time following what's being said right now, the discussion is too fast! 20:47:40 <cwickert> +1 20:47:45 <nirik> cwickert: what does 'leading edge' mean? no testing for updates, they just go directly out? 20:47:45 <dgilmore> Kevin_Kofler: changes in behaviour are expected between releases but not within a release 20:47:55 <mjg59> Wait. 20:48:09 <Kevin_Kofler> "<cwickert> skvidal, but as long as karma ls limited to FAS acount holders it's not that useful" → That's another big problem, indeed. 20:48:09 <cwickert> nirik, definitely not. I *hate* people bypassing testing 20:48:09 <mjg59> We are not discussing what types of update are acceptable 20:48:14 <pjones-> Oxf13: we really need "strawpoll.fp.o" ;) 20:48:17 <Kevin_Kofler> Most users will never bother registering with FAS. 20:48:31 <Oxf13> pjones-: haha, well.. 20:48:32 <mjg59> There is no point in us having that conversation until the board outlines its position 20:48:40 <nirik> how about this. Can we all agree with: "We would like our end users to see less Regressions and new bugs in a stable release" ? 20:48:44 <dgilmore> cwickert: people who want the lastest should be running rawhide 20:48:51 <Oxf13> mjg59: I agree with that 20:48:53 <cwickert> nirik, +1, good start 20:48:56 <dgilmore> as thats the perfect place to be doing agressive updates 20:48:57 <Kevin_Kofler> "<adamw> we can't rely strongly enough on what '+3' actually means for any given update for it to be a sane criterion for accepting or not accepting it" → Indeed! 20:48:57 <skvidal> nirik: +1 20:48:59 <abadger1999> mjg59: I disagree on the grounds that that's really fesco's job, not the boards -- but I agree that that's not what's under discussion here. 20:49:06 <Oxf13> nirik: very much in favor of that. 20:49:11 <nirik> Kevin_Kofler: your thoughts on that? drop the karma thread please? 20:49:13 <Kevin_Kofler> "<mjg59> Kevin_Kofler: This is in the week where someone described how the KDE 4.4 update broke their desktop due to various untested edge-cases?" → Those are just edge cases. For most people KDE 4.4.0 just works. 20:49:14 <mjg59> So can we *please* stick to what's currently on the table, which is discussing whether we need to enforce further testing on packages or not? 20:49:15 <cwickert> dgilmore, the latest and the greatest stable releases, not eating babies 20:49:18 <pjones-> nirik: I don't think that's all, but yes, +1 to that statement. 20:49:19 * skvidal thinks back to his cloture proposal... 20:49:22 <Kevin_Kofler> Even karma can't help there. 20:49:28 <notting> nirik: sure. and i'd go back to what Oxf13 said in that i do believe we have room for improvement 20:49:30 <Kevin_Kofler> Because 100 +1 and 97 -1 will still be +3. 20:49:40 <dgilmore> cwickert: rawhide is generally really stable 20:49:45 <ajax> boy you people are chatty. 20:49:49 * nirik waits for Kevin_Kofler to catch back up 20:49:57 <Kevin_Kofler> <skvidal> cwickert: people threatening to leave should leave 20:49:57 <Kevin_Kofler> <skvidal> orphan your packages and go 20:50:05 <Kevin_Kofler> We'll lose a lot of valuable maintainers! 20:50:11 <pjones-> nirik: you're going to be waiting a while. 20:50:21 <cwickert> mjg59, +1 for further testing 20:50:23 <dgilmore> Kevin_Kofler: i dont think we will 20:50:30 <mjg59> Kevin_Kofler: Ok. Let's just go back to the start of this. Are you willing to accept any proposal in which some level of third-party or automated testing is mandatory before a package can enter stable? 20:50:43 <Kevin_Kofler> pjones-: Funnily, what I have found "out of line with reality" is mjg59's statements. 20:50:51 <pjones-> Kevin_Kofler: seriously? 20:50:55 <Kevin_Kofler> Such as that it won't be a problem for packages to get a karma of +3. 20:51:04 <ajax> Kevin_Kofler: focus. 20:51:04 <Kevin_Kofler> Just look at the current packages and their karma values! 20:51:15 <cwickert> please people, lets try to follow mjg59, he asked a serious question 20:51:22 <nirik> Kevin_Kofler: please stop talking about karma? we are trying to move to a higher level here... 20:51:22 <dgilmore> Kevin_Kofler: i odnt think you are seeing the whole picture 20:51:25 <Kevin_Kofler> ajax: This is focusing on mjg59's proposal! 20:51:25 <pjones-> Kevin_Kofler: I'm not going to respond to that *again*. 20:51:39 <nirik> Kevin_Kofler: no, it's not. This is a general discussion on updates. 20:51:58 <mjg59> Kevin_Kofler: Could you answer my question? I think it'd make this discussion a lot easier. 20:52:05 <cjb> We can agree that karma is currently underused, but there's no reason to expect that it will stay underused when it's being actively measured. 20:52:23 <abadger1999> Kevin_Kofler: Your fellow fesco members are trying to figure out where common groiund lies so they know if there's anything they can talk about that you will contribute constructively to. 20:52:26 <pjones-> cjb: or when we guide people to actually use it. 20:52:27 <Kevin_Kofler> mjg59: Automated, maybe, if it's fast. 20:52:34 <Kevin_Kofler> Manual testing, no. 20:52:42 <dgilmore> cjb: exact;y 20:52:45 <dgilmore> exactly 20:52:48 <mjg59> Kevin_Kofler: But not any requirement that a package be installed and tested by someone other than the maintainer? 20:52:50 <Kevin_Kofler> (fast as in, completes within an hour at most) 20:53:08 <adamw> afaik there's no reason at present to believe that automated testing will introduce more than a few minutes' delay to the process, I believe 20:53:14 <Kevin_Kofler> (and as in, we prequeue to stable, AutoQA automatically confirms it and we don't have to go back to queueing it again) 20:53:14 <skvidal> adamw: please wait 20:53:18 <adamw> sorry 20:53:37 * gholms rings the fifteen minute bell 20:53:40 * nirik gets phonecall 20:53:41 <Kevin_Kofler> mjg59: As an indication, sure, but as a general requirement, no. 20:53:43 <cwickert> to answer mjg59's question: I would like some automated testing, even if it means that direct stable pushes are forbidden. I dislike prohibution, but maintainers have proven to be not reasonable enough with their updates 20:53:52 <Kevin_Kofler> Some packages don't even HAVE any known user other than the maintainer. 20:53:58 <Kevin_Kofler> Users may be there, but they don't interact with us. 20:54:03 <Kevin_Kofler> So they'll never give Bodhi karma. 20:54:10 <mjg59> Kevin_Kofler: Ok. If you're unwilling to accept any requirement that there be manual testing, then I think quibbling over the details of how manual testing is implemented is uninteresting. 20:54:25 <nirik> yep. 15min 20:54:26 <Kevin_Kofler> Well, there are solutions which are more broken than others. 20:54:32 <nirik> votes to continue discussion. 20:54:38 <nirik> +1 I think... 20:54:39 <skvidal> do we have more than a quorum w/o kevin's input? 20:54:45 <skvidal> nirik: +1 20:54:48 <pjones-> discussion of /what/ exactly? ;) 20:54:53 <Kevin_Kofler> Can we vote to defer discussion to next week? 20:54:55 * notting votes +1 to continue, in that at least we have not reached a point to define next steps 20:55:07 <mjg59> Yes, I'm +1 on some continuation 20:55:13 <pjones-> if we're going to discuss whether we're letting Kevin_Kofler filibuster, as we have been, then there's not much point. 20:55:17 <cwickert> +1 to continue 20:55:26 <gholms> Will there need to be another time extension vote in 15 more minutes? 20:55:27 <Kevin_Kofler> I'm not filibustering. 20:55:33 <nirik> ok, 15min more. 20:55:39 <nirik> gholms: yes 20:55:48 <Kevin_Kofler> I'm pointing out concrete issues with the proposals as a whole, and also with individual proposals. 20:55:57 <nirik> except I need to leave in a few to head to the vets, so I might need to pass off the chair to someone else. 20:55:57 <Oxf13> pjones-: Kevin_Kofler aside, I think there is room for the rest of fesco to discuss the proposals and what they are trying to achieve. 20:55:58 <Kevin_Kofler> mjg59,: The thing is: there are some critical regressions which need fixing ASAP. 20:56:21 <Kevin_Kofler> We can't afford to force some arbitrary amount of testing for them. 20:56:23 <mjg59> Kevin_Kofler: I think you're trying to have a conversation that nobody else is having 20:56:34 <Kevin_Kofler> There are also packages which never get any karma at all. 20:56:40 <mjg59> Kevin_Kofler: Your opinion is known at this point, everyone else is just choosing to disagree 20:56:46 <Kevin_Kofler> Or any Bodhi or Bugzilla feedback in general. 20:57:06 <dgilmore> Kevin_Kofler: stop focusing on what is and focus on what can be 20:57:09 <Kevin_Kofler> Have you seen feedback from influential people like Luke Macken or Michael Schwendt? 20:57:16 <nirik> ok, so Kevin_Kofler doesn't think any changes are needed, so should the rest of us think of the current proposals. 20:57:23 <nirik> https://fedoraproject.org/wiki/UpdatePolicy(draft) 20:57:36 <nirik> Kevin_Kofler: yes, we have. Or at least I have. I can't speak for others. 20:57:42 <ajax> Kevin_Kofler: we have, in fact, seen their feedback. and we are taking it under consideration. 20:57:49 <ajax> you, however, are repeating yourself very loudly. 20:57:49 <cwickert> as a starting point, can we all agree to: "direct stable pushes are forbidden. if necessary, they require approval by rel-eng" 20:57:54 <nirik> I think notting's proposal takes that under consideration. 20:57:55 <ajax> feel free to knock it off. 20:58:05 <nirik> as 'leaf' packages can keep doing what they want to. 20:58:07 <mjg59> cwickert: I think last week showed that we were broadly in agreement with that 20:58:18 <mjg59> cwickert: The exception is whether security updates should be subject to that 20:58:19 <cwickert> mjg59, at least something ;) 20:58:26 <nirik> cwickert: I think that runs into the karma discussion and/or testing needed. 20:58:27 <cwickert> mjg59, of course 20:58:35 <Kevin_Kofler> How would that approval work? 20:58:42 <Kevin_Kofler> One rel-eng person? 2? Vote by rel-eng? 20:58:44 <notting> cwickert: ... i could be convinced that for the far out fringe packages that passing autoqa may be enough 20:58:44 <nirik> I think it's ok for perl-NooneUses this to go direct to stable... 20:58:45 <mjg59> Kevin_Kofler: Unimportant right now 20:59:01 <mjg59> nirik: I'm a /little/ uncomfortable with that 20:59:07 <abadger1999> cwickert: I'd rather see approval by QA. 20:59:08 <Kevin_Kofler> It's not unimportant. It makes a big difference for practicability of the proposal. 20:59:08 <cwickert> nirik, no, I don't think this karma thing will really work, but testing and autoqa are better 20:59:11 <dgilmore> Kevin_Kofler: i dont see Michael Schwendt as infulencial. he choose to largely abstain from fedora years ago 20:59:12 <nirik> mjg59: with autoqa of course. 20:59:12 <skvidal> notting: I'd believe that far out fringe pkgs might fall into the category of things to be removed :) 20:59:23 <notting> cwickert: whether you're counting that as 'direct' or not, i don't know. 20:59:31 <mjg59> nirik: If a package is rarely used, that often tends to mean that the people who are using it *really* need it 20:59:52 <mjg59> nirik: So while it may be unimportant to the distribution as a whole, breakage there could have a disproprtionately large effect on those users 20:59:56 <nirik> mjg59: perhaps, but it often also means the fedora maintainer is upstream and/or heavily involved with it. 21:00:01 <mjg59> Yeah 21:00:04 * dgilmore thinks that all packages need equal treatment 21:00:14 <adamw> what does 'approval by rel-eng' mean, exactly? requiring 'approval by rel-eng' is in fact the current de facto situation, right, since they actuall have a gate on all pushes (but in practice reject almost nothing)? 21:00:24 <dgilmore> because what i think its unimportant is the most ctritical thing to someone else 21:00:30 <pjones-> dgilmore: I think they all need some form of QA, both automated and human, but it doesn't necessarily have to be in public. 21:00:33 <mjg59> adamw: Again, I think that's a detail that's not currently important 21:00:34 <Kevin_Kofler> dgilmore: He's one of the people who made Fedora Extras what it was. 21:00:42 <dgilmore> Kevin_Kofler: he chose to leave 21:00:49 <cwickert> abadger1999, +1, but why not have both requirements? if someone wants a direct stable push, he requests it from rel-eng and they let the autoqa script (or whatever) run. it's just an *additional* requirement 21:00:54 <dgilmore> Kevin_Kofler: which makes him not important 21:01:07 <dgilmore> pjones-: sure 21:01:14 <notting> well, i think having rel-eng as an arbiter is putting the decision making in the wrong place 21:01:27 <dgilmore> notting: i agree 21:01:30 <nirik> perhaps we need a updates Czar. 21:01:31 <pjones-> notting: I think that's also the case, yes. 21:01:34 <dgilmore> that are just the gate keepers 21:01:36 <adamw> mjg59: well I think it's hard to decide whether 'approval' is needed with no idea of what it entails. does that mean anyone in releng gets to reject an update they don't like? we don't have any suggestion as to what releng's approval should be predicated on, that I can see 21:01:38 <dgilmore> not the key masters 21:01:38 <Rathann|lappy> it should be QA, shouldn't it? 21:01:39 <cwickert> adamw, why is this the current situation? i can push things to stable whenever I want and rel-eng doesn't notice 21:01:40 <Kevin_Kofler> Rel-eng is already doing that for releases? 21:01:43 <abadger1999> cwickert: Wouldn't the autoqa script potentially run on all packages? Isn't who approves more a question of who does the manual testing? 21:01:47 <Kevin_Kofler> So why are they the wrong people for updates? 21:01:52 <pjones-> nirik: I'd rather have a /set/ of people who can be involved. 21:02:00 <mjg59> adamw: Right now we are trying to get a feel for what the process should roughly look like 21:02:02 <nirik> pjones-: sure /s/ 21:02:11 <notting> Kevin_Kofler: we're trying to fix that (see QA doing karma for critical path, etc.) 21:02:13 <pjones-> Kevin_Kofler: because their job is to make sure we can push updates and to get them pushed, not to evaluate the merits of them. 21:02:14 <mjg59> adamw: How various parts of it are enacted is really not relevant right now 21:02:18 <adamw> cwickert: I believe someone from releng explained early in the current discussion that in fact nothing goes to stable without releng 'accepting' it. in practice they accept almost everything, but the push process isn't automated, it doesn't just happen when you hit the button. 21:02:19 <cwickert> abadger1999, fair point 21:02:32 <mjg59> adamw: Given that we don't even have that outline. Focusing on details without having a coherent structure doesn't move us forwards. 21:02:35 <pjones-> Kevin_Kofler: giving that job to rel-eng draws in to question what we've got QA for ;) 21:02:45 <jwb> adamw, no 21:03:03 <adamw> jwb: oh, i may have misunderstood...i tried to find the post to re-check but the threads are too long :( 21:03:11 <nirik> adamw: I think that is 'relegn could reject it/edit it, but doesn't 21:03:21 <jwb> nirik, closer 21:03:24 <cwickert> adamw, I'm surprised. how did we manage do get broken deps into the release then if some rel-eng folks looked at the package? 21:03:34 <nirik> because there is no policy for them to refer to. 21:03:43 <notting> cwickert: because it is not actually practical to do so. 21:03:44 <mjg59> Anyway. While I feel that any policy we enact /should/ cover all packages, I'd be happy with it initially being done with critpath + default installation contents 21:03:45 <Kevin_Kofler> They just didn't run a depchecker. 21:03:48 <adamw> cwickert: i didn't say that they *do* check every package, i said they have a checkpoint in the current process, in theory. but IMBW. 21:03:48 <Oxf13> releng isn't actually doing any "approval" or "disapproval" of updates 21:03:58 <Oxf13> we just click the buttons that sign the packages and make the pushes happen 21:04:00 <cwickert> adamw, i see 21:04:11 * skvidal wonders how we got this far off into the weeds 21:04:14 <mjg59> Which would give us an opportunity to test how this works with commonly used packages 21:04:15 <jwb> adamw, no 21:04:18 <nirik> I think doing a subset might be good at least to start. That way we can ramp up autoqa and more testers and such... and have it more in place if we decide all packages need it. 21:04:21 <Oxf13> when there are hundreds and hundreds of requests every day it is impossible to examine each and every one to make any sort of judgment on 21:04:23 <lmacken> mjg59: I agree 21:04:26 <Oxf13> rel-eng is not the place for that. 21:04:26 <notting> mjg59: i strongly feel that any automated QA checks should be applied to *all* updates 21:04:33 <mjg59> Also, could we *please* stop talking about releng specifics right now? 21:04:40 <skvidal> mjg59: +1 21:04:46 <nirik> mjg59: +10 21:04:46 <cwickert> ok 21:04:51 <notting> mjg59: more strict checks can be restricted to some critpath + default installation set 21:04:56 <mjg59> notting: Yeah, autoqa for everything 21:05:00 <adamw> sorry, last attempt: what I'm worried about is that you all 'agree' that rel-eng gets to approve all packages without any idea of what it is releng would be doing, exactly. i'd rather look at what the criteria that we want to impose on updates are, rather than just saying 'this group gets to say yes or no'. 21:05:17 <mjg59> adamw: We're not going to decide on anything of the sort now 21:05:20 <nirik> so, how about this: everyone (in fesco), tell us what proposal you like best of the list currently. 21:05:29 <mjg59> adamw: We're certainly not going to impose responsibilities on anyone without talking to them first 21:05:38 <skvidal> nirik: in 2 lines of text or less :) 21:05:50 <notting> nirik: well, the question is if everyone's had a chance to read all of them 21:05:52 <Oxf13> I'm also in favor of 'autoqa for everything as a gateway to being pushed anywhere' and 'sufficient karma or time required for critpath packages to get into stable' 21:05:53 <nirik> nirik: I like nottings the best, but think it could use minor adjustments/discussion. 21:06:16 * nirik just wonders where everyone else is. 21:06:17 <mjg59> I like notting's, but would like it to cover everything in the default installs of the primary spins 21:06:27 <nirik> but yeah, could be no time to read them yet. 21:06:32 <jwb> mjg59, plural? 21:06:36 <skvidal> nirik: mjg59's with the testing criteria from kparals with notting's delineation of what should have all the rules enforced on it 21:06:38 <Oxf13> mjg59: wouldn't that just be a matter of expanding the critpath set? 21:06:40 <jlaska> I like autoqa for everything, but autoqa is just the framework. It would be really helpful for QA to have a deeper discussion around the specific requirements/criteria we want to use AutoQA to reinforce 21:06:45 <Oxf13> mjg59: instead of making a second set of packages? 21:06:47 <pjones-> jwb: absolutely plural. 21:06:47 <cwickert> Oxf13, I think i can agree to that, but some details need to be sorted out 21:06:53 <Kevin_Kofler> I think those proposals are all way too strict to be practical on some points. 21:07:02 <mjg59> Oxf13: Well, sure, we could redefine critpath appropriately 21:07:06 <pjones-> jlaska: that's a fair point. 21:07:11 <Oxf13> jlaska: agreed. To start with, no broken deps. 21:07:23 <skvidal> Oxf13, jlaska: please hold your comments for a moment 21:07:29 <adamw> what I wrote into the combined policy is that all updates go through the very basic automated sanity tests. 'important' packages get further manual testing, 'non-important' do not (they can be pushed direct to stable if they pass the automated tests) 21:07:31 <jlaska> skvidal: will do, apologies 21:07:36 <skvidal> I'd like to see everyone on fesco respond to nirik's request 21:07:41 <adamw> er, combined draft* 21:07:57 <skvidal> adamw: please hold your comments 21:08:05 <skvidal> we've heard from fesco members - but not all 21:08:07 <Kevin_Kofler> The maximum I could agree with would be: 21:08:17 <notting> nirik: i like mine. :P i'd be willing to drop the third part (about non-critical-path/important packages) if we want to start small 21:08:29 <ajax> i think they all sound pretty similar, tbh 21:08:33 <Kevin_Kofler> 1. AutoQA for all packages, but with some practicable manual override if AutoQA screws up, which will undoubtedly happen 21:09:06 <Kevin_Kofler> 2. at least 1 positive karma from rel-eng and/or QA before going stable for "important" packages as defined by notting 21:09:23 <Kevin_Kofler> The real critical path could even be stricter, I don't care all that much about that as long as KDE is not in it. ;-) 21:09:33 <Kevin_Kofler> 3. direct stable pushes must be allowed 21:09:43 <skvidal> is anyone else going to speak 21:09:45 <Kevin_Kofler> (i.e. I don't agree with point 3. of notting's proposal, otherwise it's not too bad) 21:09:58 <adamw> kevinverma: notting's definition of important _did_ have KDE in it. 21:10:13 * nirik was waiting for the rest of fesco... I guess we are missing, pjones-, dgilmore ? 21:10:15 * dgilmore has not read all the proposals yet 21:10:16 <Kevin_Kofler> adamw: "at least 1 positive karma from rel-eng and/or QA" is acceptable for KDE. 21:10:20 * gholms rings the 30 minute gong 21:10:22 <Kevin_Kofler> Anything stricter, not. 21:10:26 <nirik> cwickert: ? 21:10:27 <pjones-> nirik: I still can't tell what we're voting on. 21:10:37 <mjg59> pjones-: Nothing? 21:10:38 <Kevin_Kofler> And direct stable pushes need to be allowed with that 1 approval. 21:10:45 <cwickert> nirik, same problem as pjones- 21:10:55 <pjones-> mjg59: then why does nirik say we're waiting on me? 21:10:56 <nirik> pjones-: we aren't. I am asking for the people on FESCO which if any proposal they most like. 21:10:57 <mjg59> pjones-: The question was which of the proposals on https://fedoraproject.org/wiki/UpdatePolicy(draft) you found most favourable 21:10:59 <skvidal> pjones-: we're not voting 21:11:08 <Kevin_Kofler> We have 1 KDE SIG member who's also in rel-eng (rdieter). 21:11:09 * nirik notes another 15min are up 21:11:10 <dgilmore> Kevin_Kofler: you dont speak for all of KDE 21:11:16 <nirik> who wishes to continue? 21:11:18 <Kevin_Kofler> So 1 positive karma would be easy to get. 21:11:30 <dgilmore> Kevin_Kofler: considering parts of KDE are putting forward proposals you dont agree with 21:11:32 <cwickert> lets go on 21:11:32 <Kevin_Kofler> Still, I don't see it as being needed. 21:11:36 <notting> nirik: sure, why not 21:11:39 <nirik> +1 here. I would like to hear from the rest of fesco... 21:11:45 <skvidal> nirik: sure 21:11:47 <mjg59> Yeah, I think we're getting somewhere 21:11:48 <Kevin_Kofler> KDE SIG is working together on those updates anyway. 21:11:53 <cwickert> how about NOT talking about KDE? 21:11:55 * nirik notes a dog is whining at the vet's to come home, so will leave here soon. 21:11:57 <Kevin_Kofler> It's not like one rogue maintainer is pushing updates directly. 21:12:16 <nirik> any more votes to continue? 21:12:18 <dgilmore> nirik: lets not continue 21:12:18 <nirik> I see only +4 21:12:29 <nirik> oh, there's 5 21:12:37 <dgilmore> nirik: mine was a -1 21:12:41 <nirik> dgilmore: yeah, not sure it's getting us anywhere. 21:12:44 <cwickert> Kevin_Kofler, not? so what was with mc in F11 last week? 21:12:47 <mjg59> Kevin_Kofler: I think the fundamental difference here is that you feel that breaking edge-case users of stable releases is acceptable, whereas we want more testing in an attempt to reduce the number of those edge-cases 21:13:10 <Kevin_Kofler> cwickert: Sorry, that was still about KDE, because some people were talking about applying extra scrutiny to KDE. 21:13:16 <Kevin_Kofler> I don't see what it'd change in practice. 21:13:39 <ajax> well as long as you continue to define the scope of quality improvement methods to exclude kde, nothing would change for kde. 21:13:55 <pjones-> nirik: of what's there, notting's is most appealing to me so far. 21:14:00 <mjg59> Kevin_Kofler: So it's not about one rogue maintainer - it's about ensuring that even competent and procedure following maintainers get enough testing to have a significant probability of reducing the number of these edge-cases 21:14:19 * notting was proposing scrutiny for any desktop we deem important enough to do a release for, actually. 21:14:43 * nirik looks at nottings proposal again to see what he would like changed. 21:14:46 <skvidal> notting: which sounds reasonable to me 21:15:04 <Kevin_Kofler> The problem with all that extra scrutiny is when we want a quick regression fix. 21:15:05 <ajax> i do like notting's proposal. 21:15:26 <Oxf13> Kevin_Kofler: you keep saying "quick regression fix" as if we could do a new updates push ever 5 minutes 21:15:37 <nirik> notting: so 'tracked number of downloads'... would that be just a positive integer? or ? 21:15:37 <Oxf13> that's.... not the case. 21:15:51 <Kevin_Kofler> Oxf13: Getting that testing will make us miss pushes. 21:15:58 <Kevin_Kofler> And lead to days of delays. 21:16:02 <mjg59> Kevin_Kofler: You seem to keep ignoring the feedback from people with many years of direct experience in release management and software development 21:16:17 <Oxf13> Kevin_Kofler: you really expect it to take more than 24 hours to get a single karma point? 21:16:20 <Oxf13> or two karma points? 21:16:33 <Kevin_Kofler> Especially if we need to track down some group to OK our update, and even more so if that group won't be willing to OK it without doing some lengthy testing. 21:16:34 <cwickert> Oxf13, unfortunately yes 21:16:34 <mjg59> Kevin_Kofler: And that feedback is almost universally "quick regression fixes often cause other problems" 21:16:35 <notting> nirik: that's probably the fishiest part of the proposal. i'd like to figure out a way to present this info to packagers so they know if/how their testing update has been installed 21:16:55 <dgilmore> Kevin_Kofler: a "quick regression fix" would have enough people to llok at it and validate it so that it could be cleard for stable very quickly 21:16:55 <ajax> if abrt weren't useless, abrt could do this. 21:17:02 <mjg59> notting: Yeah, and that's difficult with the mirror infrastructure 21:17:07 <Kevin_Kofler> But the biggest problem with notting's proposal is point 3, not point 2. 21:17:14 <notting> mjg59: we have *a* mirror under fedora infrastructure's control 21:17:28 <Kevin_Kofler> I.e. banning direct stable pushes, even if the sufficient karma is achieved while still in pending state. 21:17:40 <ajax> nah, i'm good with that. 21:17:41 <mjg59> notting: If we can expose that, it's great 21:17:45 <Kevin_Kofler> Point 2 is mainly an annoyance. 21:17:49 <Kevin_Kofler> Point 3 is a serious issue. 21:18:10 <ajax> if they hit their karma threshold, they go to stable. what's the issue there? 21:18:43 <Kevin_Kofler> Hitting +3 before even going out to testing is a very rare corner case. 21:18:48 <Kevin_Kofler> Not worth even discussing. 21:18:52 <nirik> notting: for the crit-path/desktops pool, do they need to spend time in testing, even if they have karma needed to promote? 21:18:53 <Kevin_Kofler> It's just not going to happen. 21:19:10 <notting> nirik: no. 21:19:12 <Kevin_Kofler> This will effectively prevent fixing things as quickly as possible (i.e. in the next push, not some later one). 21:19:13 <nirik> thats kinda unclear from reading again, as point 3 says "All Other" 21:19:24 <nirik> notting: so, Kevin_Kofler is misunderstanding. 21:19:30 <jwb> i want to say something 21:19:33 <ajax> that's a polite way of putting it. 21:19:39 * nirik is happy to let jwb say something. 21:19:47 <Oxf13> so it looks to me like if an update gets sufficient karma before going into -testing, it can go directly to -stable 21:19:49 <Oxf13> I'm good with that. 21:19:55 <dgilmore> Kevin_Kofler: i believe that going forward it will be common 21:20:10 <dgilmore> Kevin_Kofler: again i ask you to picture things as they can be not what is today 21:20:10 <Kevin_Kofler> I believe that's an illusion. 21:20:10 <skvidal> jwb:? 21:20:12 <mjg59> Kevin_Kofler: If this causes extreme problems, then it's something we get to revisit 21:20:34 * nirik notes that anything we do isn't the end of the world. We can learn from it and adjust. 21:20:42 <skvidal> nirik: agreed 21:20:44 <skvidal> jwb? 21:20:56 <jwb> was waiting 21:21:24 <nirik> notting: we might put a "OR" between the 'karma' and 'time/downloads in updates' testing to make that clear. 21:21:30 <Kevin_Kofler> A week of testing for non-critical stuff just because it doesn't have some magic karma is also excessive. 21:21:47 <jwb> i just wanted to say that pushes are not automated. i don't see them being automated anytime soon. if there is some kind of urgent issue, an email or an IRC message would suffice to make sure something is included. this has been true for a long time. 21:22:11 <Kevin_Kofler> If some non-critical package hit testing, the update fixes serious bugs for those few people who do use the package and nobody screamed, why do we need to wait a full week? 21:22:15 <skvidal> jwb: indeed 21:22:28 <jwb> arguing about missing pushes and taking days is a bit of a red herring 21:22:35 <dgilmore> Kevin_Kofler: if no one is using it there is no damage done with a week in testing 21:22:52 <ajax> and if they are using it, huzzah, karma. 21:23:07 <Kevin_Kofler> As I wrote in a mail, there is a huge difference between "no one" and "no one who bothers giving Bodhi feedback". 21:23:20 <nirik> so, does anyone have further feedback for nottings proposal that we can provide? or should we gather that over the next week and see if we can vote on it next week? 21:23:28 <Kevin_Kofler> You can't assume that all users will use Bodhi. 21:23:31 <drago01> for those who don't saw the discussion in #fedora-devel earilier ... we should say "passes autoqa tests + one karma from a human" instead of "3 karma" 21:23:32 <Kevin_Kofler> This will NEVER happen. 21:23:35 <drago01> it makes more sense 21:23:45 <dgilmore> Kevin_Kofler: stop now 21:23:46 <notting> nirik: if so, i can separate those three points and we can consider each one individually 21:23:56 <ajax> no, but i can certainly get yum or pk or something to phone home with update info. 21:24:00 <cwickert> my feedback: notting's proposal is the best so far, but some details need to be sorted out 21:24:17 <nirik> drago01: see nottings proposal... 21:24:24 <mjg59> nirik: So, my understanding of this was that we would be enthusiastic about notting's proposal with some possible fiddling of precisely which packages get covered by its critpath discussion? 21:24:27 <drago01> nirik: sorry 21:24:31 * drago01 reads scrollback 21:24:34 <abadger1999> nirik: What makes releng/qa more qualified to give karma on critpath packages? 21:24:59 <abadger1999> drago01: https://fedoraproject.org/wiki/UpdatePolicy(draft)#notting.27s_Proposal 21:25:02 <nirik> mjg59: or any other points in it people would like to adjust and would be able to get it to pass. ;) 21:25:03 <Kevin_Kofler> They're a group we can ping to get an urgent update approved? 21:25:03 <pjones-> cwickert: I think the way to do this is to generally agree on a proposal, and then change the details in that proposal as appropriate. 21:25:07 <notting> abadger1999: releng, hm. qa, presumably because they tested them :) 21:25:08 <adamw> releng/qa is a fairly quick and dirty definition that was thrown together for the f13 process. we're discussing a better definition of 'qualified testers' on the test list atm 21:25:13 <drago01> abadger1999: thx 21:25:16 <cwickert> pjones-, +1 21:25:16 <nirik> abadger1999: perhaps that should be 'provenqa-er' 21:25:39 <abadger1999> notting: Does that mean releng/qa is committing to testing the packages? 21:25:50 <abadger1999> I'm hesitant about seeing them hit with the extra work... 21:25:55 <Oxf13> abadger1999: notting: I've been in discussion of killing the "releng/qa" and moving toward a "proventesters" group 21:26:04 <Oxf13> a la provenpackagers 21:26:07 <abadger1999> I think it will provoke a cycle of updates "discussions" 21:26:13 <Oxf13> people we trust to give meaningful karma 21:26:30 <Oxf13> and a group of people that can be pinged and expect to have fast turn around on testing things 21:26:33 <notting> abadger1999: as stated in the proposal " I accept that this places a 21:26:33 <notting> larger burden on QA, and would expect them to be able to contribute testing to this initiative." 21:26:36 <nirik> abadger1999: as for test criteria, I expect it to start broad and get more narrow as we get more testers and have more time. 21:26:42 <abadger1999> Oxf13: Makes a bit more sense 21:26:50 <drago01> nirik: yeah notting's proposal sounds sane to me 21:26:54 <nirik> ie, for now, I would be happy with: "I use this app day to day and it installs and works for my needs" 21:26:59 <Oxf13> abadger1999: I started with releng/qa because releng was doing the freeze break requests to begin with 21:27:08 <adamw> abadger1999: in practice it's working so far for f13, but that's not been going on for too long. right now we basically update from updates-testing, reboot, and +1 everything that didn't make stuff blow up. 21:27:15 <nirik> and someday when we have more testers we could run a test plan, or test specific bugs, or skys the limit. 21:27:16 <mjg59> I think we're at the point where there's not much more for fesco to discuss right now? 21:27:22 <Oxf13> and while QA is the logical place for this work, the qa group wasn't very big so I couldn't in good conscience dump it on their lap 21:27:23 * gholms sets off the 45 minute fireworks 21:27:25 <jlaska> nirik: right on ... in time 21:27:28 <drago01> but how do we track download numbers? 21:27:32 <Kevin_Kofler> I think point 2 in notting's proposal all hinges on whether the magic group will be able to OK updates quickly enough. 21:27:43 <mjg59> Kevin_Kofler: You *keep saying that*. 21:27:46 * nirik 's 15min alarm also just went off. 21:27:54 <dgilmore> Kevin_Kofler: Please be quiet 21:28:02 <mjg59> Ok. I'm -1 on further discussion of this right now. 21:28:05 <notting> nirik: so would you like me to update my proposal as comments come in on the list? 21:28:08 <nirik> do we want a bit more to wrap things up? or shall we work on nottings and go for next week? 21:28:10 <dgilmore> nirik: end the discussion 21:28:17 <nirik> ok. 21:28:17 * skvidal is -1 21:28:17 <ajax> drago01: like we said, we have a mirror under infra's control. we can sample that. 21:28:21 <nirik> notting: yes, please do, and the wiki page. 21:28:28 <ajax> -1 to more discussion, i think we're winding down 21:28:35 <nirik> cool, so moving on: 21:28:37 <gholms> Open floor, then? 21:28:40 <nirik> #topic Open Floor 21:28:46 <nirik> gholms: you are a mindreader. ;) 21:28:51 <gholms> :D 21:29:19 <nirik> anything for open floor? 21:29:28 <drago01> ajax: I might be missing something ... but if 1000 people download it from a different mirror and no one from the controlled one we wouldn't know right? 21:29:45 <ajax> drago01: that would be true, but would also be a pretty significant load balancing failure. 21:29:53 <notting> drago01: correct. 21:29:54 <thm> one could always argue it was not representative ;) 21:30:16 <geppetto> ajax: It doesn't count private mirrors ... but hopefully those are noise 21:30:23 <ajax> the better way - as i've said a few times now - is to sample test data from end users directly if we can 21:30:39 <jlaska> nirik: nothing crazy, but I was hoping to clarify what it means when people say AutoQA 21:30:40 <drago01> ajax: well non us fastest-mirror users would probably never use the controlled one 21:30:49 <ajax> something like abrt would be in an ideal place to notice that a package _was_ seeing crashes, got updated, and no longer crashes. 21:30:58 <nirik> jlaska: feel free. Should I change topic? oh wait. 21:31:01 <nirik> #undo 21:31:02 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x28578090> 21:31:10 <ajax> yeah python 21:31:19 <nirik> #info will work on nottings proposal over the next week and revisit next week. 21:31:28 <nirik> #topic AutoQA 21:31:38 <nirik> jlaska: ? 21:31:43 <jlaska> nirik: not a huge issue, but there is a lot of discussion in the meeting today and on the list that we can just use AutoQA to "test stuff" 21:31:52 <jlaska> that is certainly the hope, but I 21:31:53 <notting> jlaska: my reading was that autoqa runs a set of tests. some subset (maybe all) of these tests are required to pass 21:31:54 <adamw> ajax: someone suggested some abrt integration like that in the forum thread, I passed it on to jiri. seems like it may go somewhere. 21:32:00 <nirik> well, I think that was a 'someday' 21:32:19 <jlaska> just wanted to remind folks that AutoQA is just a framework for storing, and running tests when certain events occur 21:32:39 <lmacken> jlaska: what's the status of the project? 21:32:48 <jlaska> notting: yeah you got it ... the only distinction I wanted to point out is that it would be really helpful for QA to define the "test stuff" parts 21:33:03 <skvidal> jlaska: I think those will be defined as we go 21:33:13 <skvidal> jlaska: a little at a time, honestly. 21:33:15 <notting> jlaska: i expect QA to be heavily involved in the criteria. things like 'doesn't break dependencies' are the obvious ones, of course 21:33:20 <nirik> jlaska: are you reading for maintainers to start doing tests? or things are more on a repo level right now? 21:33:23 <skvidal> and they will be subject to individual arguments as they are being defined 21:33:43 <jlaska> nirik: right now we're focused on acceptance level tests ... not package specific function tests 21:33:55 <jlaska> but if there are other tests that people want ... we just need to get it on the radar 21:33:58 <nirik> but there will someday be hooks for that? 21:34:02 <Kevin_Kofler> I think we should start with a small set of error-level tests, if in doubt, make them warnings. 21:34:04 <jlaska> lmacken: the project space lists the current trigger/hooks and the tests ... https://fedoraproject.org/wiki/AutoQA 21:34:20 * nirik bookmarks 21:34:30 <Kevin_Kofler> And if we want to make AutoQA mandatory to allow pushes, a manual override is needed. 21:34:35 <Kevin_Kofler> Software WILL screw up. 21:34:43 <jlaska> lmacken: we are still trying to unbury from the java packaging deps ... and I hope we can use an upcoming FAD to get help knocking those java %buildrequires out of the way so we can deploy this 21:34:43 <nirik> Kevin_Kofler: agreed there. 21:35:02 <dgilmore> Kevin_Kofler: again please be quiet if all your going to do is bad mouth everything 21:35:09 <lmacken> jlaska: cool, thanks for the update 21:35:19 <nirik> jlaska: anything else? 21:35:24 <Kevin_Kofler> dgilmore: Huh? 21:35:29 <mjg59> Kevin_Kofler: The fact that software will always screw up is why pushing directly to stable is a problem 21:35:31 <jlaska> nirik: nothing here, thanks :) 21:35:32 <nirik> #topic Open Floor 21:35:38 <nirik> anything for open floor again? 21:35:58 <skvidal> nirik: the board recently added a policy for removing members from the board 21:36:10 <skvidal> nirik: would anyone like to discuss implementing the same policy for fesco? 21:36:16 * nirik really really has to go. If someone would be willing to mail the minutes/log to the list and update tickets he would buy them a beverage of their choice at the next fudcon. 21:36:35 <ajax> skvidal: do you have a link to their policy? 21:36:39 <nirik> skvidal: sure... perhaps write up the same procedure for fesco and we can vote/discuss it? 21:36:49 <nirik> it won't exactly apply tho. 21:36:51 <skvidal> the policy was unanimous decision -1 21:36:53 <Kevin_Kofler> Why would we want to remove members from FESCo? 21:37:16 <Kevin_Kofler> If the goal there is to kick me out, just say so. :-/ 21:37:17 <mjg59> Kevin_Kofler: Repeated failure to turn up to meetings? 21:37:22 <skvidal> nirik: I'll be glad to write it up 21:37:29 <dgilmore> Kevin_Kofler: the person never shows up to meetings 21:37:37 <mjg59> Kevin_Kofler: Basically, going AWOL is the only case I can think of 21:37:40 <Kevin_Kofler> Do we have any such person? 21:37:43 <dgilmore> is destructive to fedora in there actions 21:37:44 <ajax> not yet. 21:37:45 <gholms> The board does. 21:37:46 <pjones-> skvidal: unanimous among other members, I assume. 21:37:49 <dgilmore> Kevin_Kofler: not at the moment 21:37:51 <skvidal> pjones-: yes -1 21:38:01 <dgilmore> Kevin_Kofler: but being prepared is not a bad thing 21:38:03 <skvidal> pjones-: unanimous excepting the person who the question is about 21:38:18 <notting> dgilmore: you mean like 'attempting to hack into the fedora servers', or something? 21:38:28 <jwb> gholms, the board does? 21:38:28 <skvidal> notting: that'd be a good example 21:38:47 <dgilmore> notting: right 21:38:54 <gholms> jwb: Has such a policy, that is. 21:39:03 <Kevin_Kofler> Wow, do you really think an elected FESCo member would do something like that? 21:39:04 <jwb> oh, yes. 21:39:06 * gholms apologizes for a clearly poorly-worded sentence 21:39:07 <Kevin_Kofler> You're really paranoid! 21:39:13 <mjg59> Kevin_Kofler: I've seen people do alarmingly stupid things 21:39:21 <cwickert> mjg59, example? 21:39:25 <notting> Kevin_Kofler: i wouldn't think so. the 'not show up' case is probably more likely. 21:39:34 <nirik> anyhow, propose a policy and we can vote on it? I think 8 -1's sounds sane. 21:39:43 <cwickert> i agree to mjg59, only AWOL is a reason for me 21:39:53 <nirik> can someone end the meeting and mail the list ? 21:39:56 * nirik leaves. 21:39:56 <skvidal> ajax: http://fedoraproject.org/wiki/Meeting:Board_meeting_2010-02-25 <look under 'removal policy' 21:39:57 <mjg59> cwickert: Student sysadmin demonstrated the insecurity of a CGI script on a university server by using it to upload a couple of GB of bestiality porn 21:40:11 <Kevin_Kofler> What about an explicit AWOL policy? 21:40:26 <Kevin_Kofler> Instead of one which allows throwing out a democratically elected member for no reason? 21:40:26 <cwickert> mjg59, ok, but he's not a board member... 21:40:32 <dgilmore> cwickert: there are many other valid reasons why we would consider removing someone 21:40:36 <dgilmore> all of them extreme 21:40:45 <cwickert> dgilmore, example 21:40:48 <mjg59> cwickert: If someone had their FAS access revoked, we'd presumably want to remove them from fesco 21:40:51 <Kevin_Kofler> Like the person has to be AWOL for at least 3 consecutive meetings AND voted off. 21:40:52 <cwickert> and please a fedora-releated example 21:40:58 <cwickert> mjg59, sure 21:41:15 <dgilmore> cwickert: somoene on fesco gets a new job that causes a conflict of interest 21:41:19 <pjones-> I'd rather a policy that allows us to remove a member for unforseen reasons. 21:41:26 <skvidal> pjones-: agreed 21:41:40 <skvidal> I'll write up something for next week 21:41:51 <dgilmore> cwickert: a fesco member who gets upset for whatecver reason and loudly proclaims i am FESCo Fedora is evil and sucks 21:41:54 <cwickert> dgilmore, in the past our members have been responsible enough to step back themselves 21:41:58 <cwickert> think of knurd 21:42:13 <cwickert> dgilmore, no reason IMHO 21:42:24 <skvidal> cwickert: okay, then vote against it :) 21:42:24 <dgilmore> cwickert: right but having apolicy just in case i think its good 21:42:32 <jwb> https://fedoraproject.org/wiki/Board/SuccessionPlanning 21:42:32 <Kevin_Kofler> I'm worried that this will undermine democracy. 21:42:46 <jwb> the Board policy is in that page under 'Removal' 21:42:49 <cjb> do you actually need a policy? is it not the case that FESCo can already just decide they're going to vote on removing a member? 21:43:06 <Kevin_Kofler> Whenever you don't like a member, you'll be able to just vote him/her off. 21:43:07 <pjones-> cjb: well, hard to say. 21:43:14 <cwickert> skvidal, +1 for having a policy, just in case, but -1 for anything that undermines democracy 21:43:16 <ajax> Kevin_Kofler: i'm worried that you think democracy is a good way to run a ship. 21:43:18 <pjones-> cjb: there's currently no governance either way. 21:43:19 <dgilmore> cwickert: if someone is doing destructive things to harm fedora image. or being malicious. i think its ok and of course it requires that every fesco member excepte the person involved to agree 21:43:39 <mjg59> Kevin_Kofler: And will then have to answer to the electorate for their actions 21:43:43 <mjg59> However: 21:43:48 <skvidal> cwickert: undermining democracy is funny 21:43:50 <cwickert> dgilmore, "harm" and "malicious" are open to interopretation. who is to decide? 21:43:57 <skvidal> cwickert: the rest of fesco 21:43:59 <dgilmore> Kevin_Kofler: if we started just voting people off people would question what we are doing 21:44:01 <mjg59> I'm not in favour of enacting a policy like this with a straight majority vote 21:44:09 <dgilmore> cwickert: the other 8 fesco members 21:44:10 <cwickert> skvidal, this is the beginning of the end then 21:44:15 <dgilmore> cwickert: all of who have to agree 21:44:15 <skvidal> mjg59: you're not in favor of voting on the policy? 21:44:21 <ajax> mjg59: the board vote did require 2/3 majority. 21:44:25 <mjg59> skvidal: Not if we're going for a straight majority, no 21:44:26 <Kevin_Kofler> cwickert: +1 21:44:29 <jwb> ajax, no 21:44:34 <Kevin_Kofler> I'm glad I'm not the only one who thinks like that. :-) 21:44:34 <skvidal> mjg59: I'm confused 21:44:43 <jwb> ajax, the board policy requires unanimous -1 21:44:49 <ajax> jwb: adding the policy was 2/3. 21:44:58 <jwb> ajax, ah, yes 21:44:59 <skvidal> jwb: actually I was wrong - the policy did say 2/3rd + FPL 21:45:05 <ajax> my ambiguity. sorry. 21:45:05 <jwb> skvidal, no 21:45:06 <cwickert> ok, how about someone drafts a policy and we vote on it next week? 21:45:16 <skvidal> cwickert: right 21:45:18 <mjg59> I think requiring the FPL's involvement would help 21:45:27 <jwb> skvidal, the removal policy is unamimous -1. amending the succession planning document is 2/3 21:45:33 <skvidal> ah 21:45:35 <skvidal> gotcha 21:45:50 <mjg59> In that if the FPL is trying to make your life miserable, you're clearly causing problems 21:45:50 <skvidal> I'm going to write a proposal up - we can discuss it a bit at a later date 21:45:53 <skvidal> this is not time sensitive 21:46:03 <skvidal> mjg59: well, I wouldn't go that far! :) 21:46:10 <dgilmore> arer we over 15 minutes? 21:46:15 <skvidal> I hope so 21:46:21 <skvidal> everyone want to close the meeting? 21:46:22 <skvidal> yay! 21:46:35 <pjones-> yes. 21:46:36 <cwickert> close please 21:46:42 <skvidal> does anyone other than nirik know how to send the logs, etc? 21:46:42 <mjg59> #action skvidal to write up proposal for FESCO member removal 21:46:42 <dgilmore> #endmeeting -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
