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