19:00:01 <nirik> #startmeeting FESCO (2010-03-16)
19:00:02 <zodbot> Meeting started Tue Mar 16 19:00:01 2010 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:05 <nirik> #meetingname fesco
19:00:06 <zodbot> The meeting name has been set to 'fesco'
19:00:11 <nirik> #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones cwickert mjg59
19:00:12 <zodbot> Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 nirik notting pjones skvidal
19:00:17 <nirik> #topic init process
19:00:23 <pjones> I suppose I'm here.
19:00:25 * skvidal is here
19:00:25 * cwickert is here
19:00:33 <mjg59> Here
19:00:40 <ajax> a friend in need is a friend indeed
19:01:05 * notting is here. behind on some stuff, but here.
19:01:15 <Kevin_Kofler> Present.
19:01:31 <nirik> dgilmore: you around?
19:01:41 <skvidal> I just pinged him on jabber
19:01:46 <nirik> skvidal: thanks.
19:01:58 <dgilmore> nirik: i am
19:02:11 <nirik> ok, I would like to leave the updates policy for last, so hopefully we can get the rest of these agenda items taken care of...
19:02:24 <nirik> #topic #353 provenpackager request for walters
19:02:30 <nirik> .fesco 353
19:02:31 <zodbot> nirik: #353 (provenpackager request for walters) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/353
19:02:52 <pjones> I think we should give it to him.  Seriously.
19:03:01 <mjg59> I can't see any reason why not
19:03:18 <Kevin_Kofler> I'm a bit worried about his plans to touch packages he doesn't own to add things which aren't in the guidelines.
19:03:29 <cwickert> +1
19:03:38 <Kevin_Kofler> And it was the only reason given for the request.
19:03:39 <dgilmore> im +1
19:03:47 <nirik> I'm +1 on it... I think it will help fedora to have him able to work on other items. I agree he shouldn't add things that are outside the guidelines.
19:03:51 <Kevin_Kofler> So I'm afraid I have to vote -1 due to lack of a valid rationale.
19:03:52 <dgilmore> I think he will be responsible
19:03:55 <notting> i'm +1 just for the desktop co-maintenance aspect
19:04:00 <mjg59> +1
19:04:01 <skvidal> +1
19:04:17 <cwickert> I agree with Kevin_Kofler. It's not that I think he is a bad maintainer, but the rationale is poor
19:04:34 <skvidal> cwickert: so you're not +1?
19:04:36 <pjones> Kevin_Kofler: I still don't know why you think he's going to run all across every package or something.  he's talking about changing a smallish group of packages as a (benign) experiment, AFAICS.
19:04:47 <cwickert> skvidal, I was +1 to what Kevin_Kofler said
19:04:49 <pjones> I'm also +1 purely for the desktop co-maintenance aspect.
19:04:50 <ajax> the guideline, if it existed, would be optional anyway.
19:04:57 <skvidal> cwickert: so not to the proposal
19:05:03 <cwickert> right skvidal
19:05:07 <nirik> #agreed walters approved for provenpackager
19:05:12 <skvidal> cwickert: sorry, that wasn't clear fro mthe flow
19:05:15 <ajax> (+1 to provenpackager, for the record)
19:05:30 <nirik> #topic #352 Proposal: Fesco should have a procedure for removing members of fesco
19:05:34 <nirik> .fesco 352
19:05:38 <zodbot> nirik: #352 (Proposal: Fesco should have a procedure for removing members of fesco.) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/352
19:05:43 <nirik> there was some discussion of this in the ticket.
19:05:52 <cwickert> skvidal, my bad
19:06:25 <pjones> I think this should get s/Chair/Chair or de facto chair/ injected into it at the obvious place.
19:06:28 <Kevin_Kofler> I still think this policy needs to be restricted to concrete wrongdoings, not just "voting off".
19:06:32 <pjones> otherwise I'm pretty much for it.
19:06:43 <pjones> Kevin_Kofler: afraid you've done some of them?
19:06:55 <Kevin_Kofler> No.
19:07:03 <ajax> pjones: "de facto chair"?  who would that be?
19:07:09 <skvidal> ajax: if the chair is absent
19:07:11 <skvidal> repeatedly
19:07:13 <skvidal> for example
19:07:14 <pjones> ajax: whoever is acting as chair if chair is missing.
19:07:17 <skvidal> and we have some sitting in
19:07:17 <nirik> I admit it's vuage... I suppose the fact that it would take 8 to do it would cause it to not be done lightly?
19:07:19 <Kevin_Kofler> I just don't think it makes sense to allow "voting off" people without a specific concrete reason.
19:07:36 <skvidal> nirik: I think it makes it fairly difficult, yes
19:07:37 <pjones> Kevin_Kofler: it requires a specific reason - it just doesn't require that the policy enumerated them all.
19:07:38 <cwickert> I think "serious misconduct" is to vague.
19:07:38 <Kevin_Kofler> And we should clarify beforehand what those concrete reasons are.
19:08:00 <Kevin_Kofler> cwickert: Right, "serious misconduct" is not concrete.
19:08:00 <notting> i would agree, but i don't think attempting to list all the things that could possibly qualify as 'serious misconduct' is practical
19:08:00 <skvidal> cwickert: if we get specific then we end up writing ourselves into a corner
19:08:01 <nirik> well, it's hard to list all the possible things that could come up
19:08:02 <Kevin_Kofler> It's abstract. :-)
19:08:06 <dgilmore> im +1 for the proposal
19:08:16 * skvidal is +1 too
19:08:17 <mjg59> Any policy which tries to enumerate concrete reasons will either fail in an awkward corner case or will have people try to push any situation they want into one of those concrete cases
19:08:29 <cwickert> I think if we really go for something like "serious misconduct", skvidal would be in danger of being removed for some os his statements in the last meeting
19:08:39 <dgilmore> I think that there would be a good obvious reason for removing someone.  the community would uproar if there was not
19:08:49 <notting> i would assume it would be like stewart definition of obscenity
19:08:51 <skvidal> cwickert: bring it
19:08:56 <pjones> cwickert: I don't think you could get us all to agree to that; therefore, you're incorrect.
19:09:01 <Kevin_Kofler> Without requiring a concrete reason, this undermines democracy.
19:09:16 <pjones> notting: I can't define it, but I know it when I piss on your mom?
19:09:17 <ajax> people.  let's save the personal attacks for the octagon.
19:09:20 * drago01 notes that there is something called "common sense" ... you don't have to write _everything_ down
19:09:31 <cwickert> skvidal, see mschwend's mail on f-a-b list
19:09:33 <skvidal> cwickert: and I'd love to see what the serious misconduct is
19:09:35 <skvidal> cwickert: hahahaha
19:09:39 <pjones> yeah, I really think this is a fine policy.
19:09:41 <notting> pjones: classy.
19:09:41 <nirik> Kevin_Kofler: well, for example the us has 'high crimes and misdemenors'... but thats also subject to subjective issues.
19:10:15 <skvidal> this policy is simply following on the board's policy
19:10:22 <pjones> I think subjective vague criteria is fine here.
19:10:23 <Kevin_Kofler> dgilmore's downplaying of the current contributions of one of Fedora's most longstanding contributors could also qualify as "serious misconduct".
19:10:24 <dgilmore> without listing evry possible thing and then missing something you cant be overly speciifc in the policy
19:10:26 <skvidal> I find it amusing that we're having more complicated discussion of it than they have
19:10:26 <cwickert> skvidal, "orphan your packages and go. I'll be glad to clean up that mess" IMHO is serious misconduct
19:10:36 <Kevin_Kofler> We really need to define what exactly is serious enough to get one voted off.
19:10:36 <ajax> i would be for this proposal with pjones' amendment about de facto chair, and with a standard impeachment rule that the cause for the vote must be made explicit.
19:10:37 <pjones> so long as it's clear that there must be some concrete reason for the removal vote.
19:10:51 <dgilmore> i think it will be obvious when we need to remove someone
19:10:54 <pjones> ajax: exactamundo.
19:10:58 <skvidal> cwickert: then by all means - vote for the policy
19:10:59 <mjg59> cwickert: I think it's inappropriate, but not serious misconduct. So, in its proposed form, the proposal would not have resulted in Seth being removed
19:11:13 <skvidal> cwickert: and then argue for my removal.
19:11:19 <skvidal> cwickert: that's how it is supposed to work
19:11:25 <cwickert> skvidal, it was not my intention
19:11:25 <mjg59> Ok. How about we vote on the amendment?
19:11:33 <pjones> mine or ajax's or both?
19:11:43 <mjg59> ajax's subsumes yours
19:11:43 * notting is +1 to the proposal with ajax's amendments
19:11:46 <cwickert> my question is: who is to define "serious misconduct"?
19:11:46 <mjg59> So let's go with that first
19:11:51 <mjg59> nirik: ?
19:11:59 <skvidal> cwickert: WE ARE
19:12:01 * skvidal is +1
19:12:03 <nirik> I'm +1 to the proposal with ajax's amendments...
19:12:08 * pjones is +1 to ajax's
19:12:09 <mjg59> +1 from me
19:12:12 <cwickert> skvidal, simple majority?
19:12:19 <Kevin_Kofler> mjg59: That's why "serious misconduct" needs to be defined.
19:12:25 <mjg59> Kevin_Kofler: Nonsense.
19:12:27 <ajax> obviously i'm in favor of my own proposal.
19:12:34 <nirik> cwickert: no, it would be 8 of 9 of us agree the other was doing 'serious misconduct'
19:12:39 <pjones> cwickert: any one of us can come and say "hey, I think you're engaging in serious misconduct."  then we discuss it as a group and decide if, by unanimous vote, we want rid of the plausible misconductor.
19:12:39 <skvidal> cwickert: did you even read the policy? the FESCO member in question may be removed by unanimous vote of the other members of FESCO
19:12:40 <mjg59> Kevin_Kofler: If it's not defined, it gets interpreted by the current committee
19:12:55 <Kevin_Kofler> I'm -1 to the policy with or without ajax's amendment.
19:13:09 <pjones> of course you are.
19:13:19 <cwickert> skvidal, this is the second step AFTER voting if something is "serious"
19:13:24 <skvidal> cwickert: no
19:13:36 * nirik tries to tally
19:13:41 <ajax> cwickert: yeah, i don't really think that's the case...
19:13:44 <pjones> cwickert: no, it's one step.  "I think you're engaging in serious misconduct.  "
19:13:44 <skvidal> nirik: I see 4 +1 and 1 -1
19:13:46 <mjg59> Kevin_Kofler: So, obviously, it would be possible for everyone to decide that the use of the word "KDE" was serious misconduct, and then vote someone off because of that. But then nobody would ever listen to that committee about anything again ever, the board would get involved and things would get fixed.
19:13:48 <Kevin_Kofler> pjones: Is this an implied accusation? :-/
19:13:54 <pjones> Kevin_Kofler: no.
19:14:01 <nirik> skvidal: did you get dgilmore's? I think it's 5 +1 and 1 -1
19:14:06 <mjg59> skvidal: I see 5 +1
19:14:11 <skvidal> nirik: I missed his
19:14:12 <skvidal> you're right
19:14:13 <skvidal> sorry
19:14:18 <pjones> Kevin_Kofler: I think you're generally against everything you didn't write, but that's not misconduct, it's just annoying.
19:14:29 <mjg59> Shall we move on?
19:14:30 <ajax> cwickert: i mean, it doesn't even matter.  if a simple majority says something is "gross misconduct", and it goes to a vote, and it's still only simple majority, then it's no effect.
19:14:33 <nirik> can we drop the back and forth please?
19:14:38 <skvidal> in favor we have: nirik, skvidal, notting, pjones, mjg59, dgilmore
19:14:39 <cwickert> pjones, ok, but what if we all agree if this or that is serious but not if foo should be removed? this are two different decisions IMO
19:14:46 <ajax> skvidal: and myself.
19:14:49 <pjones> cwickert: only the last one matters.
19:14:53 <skvidal> ajax: of course, right
19:14:55 <skvidal> so it's in
19:15:00 <nirik> #agreed the proposal passes with an amendent for the chair/current acting chair.
19:15:00 <skvidal> nirik: I think we're done, right?
19:15:14 <pjones> nirik: you got that wrong
19:15:17 <nirik> skvidal: yes, except can someone write this up in the wiki and announce it?
19:15:23 <nirik> pjones: ok.
19:15:24 <Kevin_Kofler> pjones: I'm against everything that doesn't make sense.
19:15:25 <nirik> #undor
19:15:27 <nirik> #undo
19:15:27 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x284fbd10>
19:15:30 <Kevin_Kofler> Whether I wrote it or not is irrelevant.
19:15:31 <ajax> cwickert: this is why i said the charge needs to be written.
19:15:33 <nirik> pjones: care to try?
19:15:33 <pjones> Kevin_Kofler: I know that to be false.
19:15:43 <mjg59> Hurrah for meetbot!
19:15:50 <skvidal> mmm, democracy successfully undermined
19:15:59 <pjones> #agreed  the proposal passes with an amendent for the chair/current acting chair and  with a standard impeachment rule that the cause for the vote must be made explicit.
19:16:04 <cwickert> ajax, just for the record what exactly was your amendment?
19:16:17 <nirik> pjones: thanks.
19:16:26 <ajax> cwickert: i might think that pjones needs to be removed because he called me fat.  but if he's brought to vote for sabotaging other people's packages, when he didn't, i would be acting in bad faith if i voted to remove him anyway.
19:16:28 <nirik> who will write this up /announce it?
19:16:31 <pjones> cwickert: exactly as quoted just now
19:16:37 <pjones> ajax: fat.
19:16:55 <ajax> 15:10 <ajax> i would be for this proposal with pjones' amendment about de facto chair, and with a standard impeachment rule that the cause for the vote must be made explicit.
19:16:59 <ajax> cwickert: ^^^
19:17:07 <skvidal> nirik: I'll write it up
19:17:20 <skvidal> nirik: and post a draft to the wiki - where should it be put in?
19:17:30 <nirik> skvidal: thanks. Should go in the fesco policy wiki space and go to devel-announce I would guess? or should we announce it?
19:17:53 <pjones> I don't think there's any real need for an announcement.
19:18:01 <Kevin_Kofler> And why can such a policy be passed with only 6 +1 votes when those wouldn't be sufficient to carry the power of voting somebody off even under the policy itself.
19:18:01 <adamw> devel-announce doesn't seem right. it's nothing specific to development.
19:18:02 <notting> given that we have Board/SuccessionPlanning, i suspect it would go in FESCo/SuccessionPlanning, or similar
19:18:04 <nirik> yeah, perhaps not.
19:18:22 <nirik> ok, moving on.
19:18:22 <Kevin_Kofler> This is quite illogical.
19:18:27 <cwickert> ajax, thanks, IMO this is not enough, so just for the record I'd like to point out that I'm -1 to the current proposal
19:18:34 <cwickert> anyway, lets move
19:18:36 <nirik> #topic #354 Desktop Spin size change should get a feature page
19:18:42 <nirik> .fesco 354
19:18:43 <zodbot> nirik: #354 (Desktop Spin size change should get a feature page) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/354
19:19:14 <dgilmore> +1  we need to make it loud and clear that you must have a dvd for the live image
19:19:36 <pjones> why does it need a feature page?  it needs to be announced, but that's handled in the second comment.
19:19:38 <mjg59> s/dvd/dvd or usb stick/
19:19:45 <mjg59> But yeah, this seems like something that's worth noting
19:19:48 <notting> i'm waffling on this. if it's prominent in the release notes, i'm not sure it needs a specific Feature page
19:19:57 <nirik> https://fedoraproject.org/wiki/Features/DesktopLiveImageTarget
19:19:57 <ajax> +1 to announcing it somehow, and not just because i hate the live installer.
19:20:03 <Kevin_Kofler> FWIW, AFAIK we're still targeting 700 MB for KDE (the Alpha overflowed due to bad kickstarts).
19:20:06 <pjones> it's already /in/ the release notes.  we do not need a feature.
19:20:08 <dgilmore> pjones: because the feature pages is where the release notes come from
19:20:11 <Kevin_Kofler> So we can point the CD users to the KDE spin. :-)
19:20:17 <pjones> dgilmore: not the documentation beat?
19:20:19 <adamw> i definitely think it needs to be announced (I mailed a suggestion to that effect to the -desktop mailing list). it's catching quite a lot of users by surprise
19:20:21 <nirik> Kevin_Kofler: or lxde/xfce. ;)
19:20:22 <drago01> or to the 1990s
19:20:23 <mjg59> pjones: I think "300MB more software" is a feature
19:20:26 <adamw> they tend to assume it's a bug and ask if they should report it
19:20:41 <ajax> well it'll get reported no matter what we do...
19:20:47 <nirik> a feature page will mean press will pick it up more.
19:20:55 <adamw> sure, but the existence of that behaviour rather indicates it needs an announcement :)
19:20:57 <Kevin_Kofler> (Actually, the reason for the KDE spin overflowing was bad timing of freeze overrides and stuff, not really the kickstart's fault.)
19:20:59 <nirik> there already is a release note.
19:21:15 <cwickert> +1 for a feature page, this needs to be in the release notes and in the wiki, so it is a feature
19:21:21 * nirik is a +1 I guess. It seems kinda a pain, but I think it will help.
19:21:30 * pjones is -1 because it seems redundant.
19:21:42 <mjg59> +1
19:21:51 <notting> before i vote +1, who are we telling to write the page?
19:22:00 <notting> that should probably be part of what we're deciding :)
19:22:01 <Kevin_Kofler> It's already written.
19:22:05 <Kevin_Kofler> https://fedoraproject.org/wiki/Features/DesktopLiveImageTarget
19:22:08 <nirik> notting: the desktop folks have a draft... see my link above
19:22:25 <notting> oh. so this is essentially ACKing an existing (late) feature page. ok, +1
19:22:36 <Kevin_Kofler> +1, the feature page is written and it's an important change which should be mentioned.
19:22:42 <pjones> if the problem is that people won't notice because they don't read the release notes, adding a feature page is only perpetuating the problem.
19:23:03 <Kevin_Kofler> "User Experience" is wrong.
19:23:09 <Kevin_Kofler> (copied from another feature page)
19:23:09 <nirik> pjones: sure, but its a nasty cycle...
19:23:13 <notting> pjones: that is a large problem to solve than just the context of this single feature. unless this is your line in the sand? this far, no farther?
19:23:28 <EvilBob> pjones: users don't read, does not mean that it should not be documented
19:23:40 <pjones> notting: my line of the sand with feature pages is well behind us, and I'm not going to be the one dragging us farther from it.
19:23:47 <nirik> #agreed This late feature is approved. Please finish up the page and add it to the right categories/lists.
19:23:48 <cwickert> we already have 5 +1s I think, have we?
19:23:52 * nirik nods
19:23:52 <adamw> EvilBob: pjones' line of thinking is that providing a Feature page to try and get the news to people who don't read release notes is a workaround not a proper fix
19:24:10 <adamw> EvilBob: where the 'proper fix' would be reprogramming users' brains with a large lump of wood with rusty nails in it until they *do* read release notes
19:24:17 <skvidal> adamw: and it is sorta like giving someone a pamphlet on illiteracy
19:24:17 <nirik> #topic #346 Drop LSB package
19:24:20 <EvilBob> adamw: +1
19:24:25 <nirik> .fesco 346
19:24:25 <zodbot> nirik: #346 (Drop LSB package) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/346
19:25:04 <notting> -1. it has a willing, if occasionally vacant packager. if we dropped everything i thought was crazy.....
19:25:04 <nirik> the list pointer in question is about the tor package (an upcoming topic)
19:25:05 <pjones> as much as I love the idea of dropping the lsb package, I think this is the wrong thing to do unless we've at least e.g. made a policy that says not to use lsb stuff for init scripts.
19:25:09 <Oxf13> competent packaging/reviews are hard, lets go shopping?
19:25:12 <pjones> (which I think we /should/ do.)
19:25:30 <pjones> we should certainly try to make as little as possible in the distro depend on it
19:25:33 <skvidal> dropping lsd is probably not a good idea
19:25:33 <notting> there's already a bug for making redhat-lsb more granular
19:25:40 <skvidal> oh, wait - you said lsB!
19:25:42 <Kevin_Kofler> pjones: BTW, #354 is something I voted for and I didn't write. :-)
19:25:42 <ajax> says you.
19:26:04 <pjones> Kevin_Kofler: a miracle!
19:26:07 <mjg59> I'm not enthusiastic about dropping a package just because someone misused it
19:26:22 <pjones> so obviously -1 on the title to this proposal.  but what /should/ be done?
19:26:26 <ajax> i would rather see lsb split more granularly, and have a guideline that packages in fedora should not depend on the umbrella package.
19:26:36 <nirik> I am -1 on this at this time, but think we should ask packaging to see about adding a guideline to not use lsb... then retire it when nothing uses it.
19:26:41 <ajax> the umbrella package is for portability for ISVs.
19:26:44 <Kevin_Kofler> The rationale for dropping redhat-lsb is that we don't actually guarantee any level of actual LSB compliance.
19:26:47 <dgilmore> -1
19:26:47 <mjg59> Yeah, it makes sense for the lsb code to primarily be there for *non*-Fedora packages
19:26:53 <pjones> or would we rather discuss this with #347?
19:26:59 <Kevin_Kofler> And in fact some of the tools don't even work and don't get fixed, if Enrico is telling the truth.
19:27:12 <notting> Kevin_Kofler: nor do we guarantee POSIX compatibility, but we don't drop -D_USE_POSIX
19:27:15 <ajax> i think 347 is a separate issue...
19:27:16 <mjg59> Kevin_Kofler: We don't actually guarantee any level of actual POSIX compliance either
19:27:17 <cwickert> -1, dropping is not a solution. but what IS the solution here?
19:27:29 <skvidal> change the policy
19:27:30 <Kevin_Kofler> That said, I'm also -1 to dropping the package.
19:27:40 <notting> so, i think the proposal failed
19:27:41 <ajax> notting: what's the bug # for splitting lsb further?
19:27:41 <Kevin_Kofler> But the right solution is to explicitly ban packages from using it.
19:27:48 <nirik> #agreed This proposal is rejected.
19:27:48 <mjg59> The lsb package does need fixing, so if the maintainer isn't doing that then we should probably contact him directly
19:28:08 <nirik> perhaps we could ask for/get more lsb package maintainers?
19:28:09 <notting> proposal: have FPC investigate a guideline against direct dependencies on redhat-lsb?
19:28:19 <notting> ajax: 47263{0,3}
19:28:22 <mjg59> notting: I'd be +1 on that
19:28:23 <nirik> +1 to nottings proposal.
19:28:32 <ajax> +1 @notting
19:28:32 <notting> also 245494
19:28:36 <cwickert> notting, +1, good starting point
19:28:39 <skvidal> +1
19:28:40 <Kevin_Kofler> The tor package's abuse of redhat-lsb probably also violates the initscripts guidelines, but we'd also want to avoid any other redhat-lsb deps in Fedora packages.
19:28:50 <pjones> +1 to notting
19:28:53 <Kevin_Kofler> +1 to the above proposal from notting.
19:28:57 <pjones> Kevin_Kofler: that's the next topic
19:29:03 <pjones> (maybe next, certainly later)
19:29:10 * notting is +1 to his own proposal
19:29:18 <dgilmore> +1
19:29:24 <nirik> who will take this to packaging?
19:29:48 <notting> i can
19:29:57 <nirik> #agreed FESCo asks FPC investigate a guideline against direct dependencies on redhat-lsb
19:30:11 <nirik> #action notting will ask them to look into it.
19:30:20 <nirik> #topic #347 tor is not compliant with Fedora guidelines
19:30:25 <nirik> .fesco 347
19:30:27 <zodbot> nirik: #347 (tor is not compliant with Fedora guidelines) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/347
19:30:49 <nirik> I am still confused about which guideline it's not meeting... non 0 return from post?
19:30:59 <nirik> .fesco 347
19:31:00 <zodbot> nirik: #347 (tor is not compliant with Fedora guidelines) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/347
19:31:06 <Kevin_Kofler> I see at least 2 guideline compliance issues:
19:31:08 * nirik fails a up arrow. ;)
19:31:13 <ajax> nirik: i think the consensus was that we really wished "output from %post" was a guideline, but that it's not.
19:31:14 <Kevin_Kofler> 1. noisy scriptlet output and
19:31:28 <pjones> ajax: yeah, looks that way to me.
19:31:29 <Kevin_Kofler> 2. non-usage of standard initscripts scriptlet snippets.
19:31:32 <nirik> Kevin_Kofler: there is no guideline against scriptlet output. ;(
19:31:51 <Oxf13> there is just cranky releng / qa folks when that happens
19:31:57 <Kevin_Kofler> I think the usage of subpackages for the initscripts is also outright bizarre.
19:32:10 <Oxf13> although I think we'd prefer that failures did get logged somewhere, but perhaps not all over the screen
19:32:11 <pjones> I think I'm more concerned that it's using the lsb initscripts stuff than that it's using "nonstandard" scriptlets.
19:32:14 * dgilmore does not see what it is volating
19:32:16 <Oxf13> or lost behind packagekit
19:32:21 <dgilmore> though it could probably be cleaner
19:32:23 <Kevin_Kofler> He should use the one style of initscripts we support (as written in the guidelines) and put those in the main package, using the standard snippets.
19:32:50 <Kevin_Kofler> Oxf13: This isn't actually a failure, at least not one that matters to the actual user.
19:33:02 <notting> scripts, for reference: http://fpaste.org/8mIc/
19:33:11 <Oxf13> Kevin_Kofler: I'm talking in general, not specific to Tor
19:33:13 <Kevin_Kofler> And it wouldn't happen if his initscripts-related snippets were compliant with the initscripts guidelines.
19:33:14 <nirik> for the record I dispise the tor and clamav packaging. I find it overcomplex, confusing for users, difficult for other maintainers, and for no gain for 99.99% of fedora users.
19:33:23 <skvidal> nirik: +1
19:33:28 <nirik> that said, I don't think it's violating any guidelines. ;(
19:33:34 <Oxf13> Kevin_Kofler: I do twitch a little when I see 2>&1 > /dev/null stuff in scriptlets
19:33:51 <dgilmore> nirik: i generally dont like the fedora-usermanagement stuff
19:33:52 <Kevin_Kofler> nirik: IMHO it violates both the letter and the spirit of the guidelines for initscripts.
19:34:04 <dgilmore> ebut im not about to ask that it be removed
19:34:08 <Kevin_Kofler> But all the other Enrico-isms are also weird.
19:34:13 <ajax> okay, so, i count two issues
19:34:13 <Kevin_Kofler> Subpackage abuse in particular.
19:34:31 <ajax> 1) not using standard initscripts practice: http://fedoraproject.org/wiki/Packaging/SysVInitScript
19:34:57 <ajax> 2) chatty scriptlets are lame
19:35:19 <ajax> 2 is pretty clearly just something someone needs to write down.
19:35:33 <ajax> you can't rely on scriptlet output ever being seen
19:35:44 <nirik> ajax: except new yum does save it. ;)
19:35:49 <notting> we only ban interactive scriptlets?
19:35:49 <pjones> so I propose that we ask FPC to codify #2, and in the mean time ask enrico to fix #1
19:35:59 <pjones> notting: right, not noisy ones.
19:36:12 <dgilmore> pjones: thats reasonable
19:36:48 <ajax> pjones: he will almost certainly refuse to fix #1 until #522053 is fixed
19:37:04 <ajax> which is fair, i suppose
19:37:13 <nirik> .bug 522053
19:37:15 <zodbot> nirik: Bug 522053 install_initd fails on Required-Start - https://bugzilla.redhat.com/show_bug.cgi?id=522053
19:37:17 <pjones> ajax: my thought was more that he shouldn't be using install_initd ...
19:37:27 <Kevin_Kofler> Indeed.
19:37:43 <Kevin_Kofler> install_initd has no business being used by any Fedora package.
19:37:53 <Kevin_Kofler> The initscript guidelines clearly write down what to use.
19:37:56 <pjones> install_initd, while broken, seems like something exclusively reserved for non-fedora packages.
19:38:04 <ajax> does he have other packages where he does this?
19:38:04 <cwickert> exactly
19:38:04 <nirik> ok, shall we vote on pjones proposal?
19:38:09 <mjg59> +1
19:38:12 <pjones> +1
19:38:13 <cwickert> ajax, I hope not
19:38:14 <nirik> +1 here
19:38:17 <ajax> +1 @pjones
19:38:20 <cwickert> +1 to pjones
19:38:24 <Oxf13> before it's lost, I think what pjones just said should be added tothe initscripts guideline
19:38:25 <skvidal> +1
19:38:30 <Oxf13> (not using install_initrd within Fedora)
19:38:31 <Kevin_Kofler> +1 to pjones's proposal.
19:38:37 <nirik> ajax: I don't think clamav does, because clamd only ships a sample script you must modify for your specific use case.
19:38:40 <ajax> cwickert: i have to imagine he does it this way because he thinks there's some good reason to
19:38:53 <pjones> Oxf13: that should be an FPC dictum, I suspect.
19:38:57 <dgilmore> +1 to pjones
19:39:01 <pjones> (so let's ask them to ban it ;)
19:39:18 <Oxf13> pjones: just what I meant.
19:39:24 * notting closes 522053
19:39:25 <nirik> #agreed FESCo will ask tor maintainer to not use install_initd and will see if FPC can codify scriptlet output issues.
19:39:29 <Kevin_Kofler> pjones: It's a bit redundant with banning redhat-lsb usage entirely as we've just asked FPC to.
19:39:36 <Oxf13> ajax: he uses Fedora packages, but not really Fedora.  He hacks the crap out of it for his own personal OS
19:39:43 * nirik wonders if he summed up correctly what people voted for?
19:39:43 <pjones> Kevin_Kofler: I'm all for one action that bans both
19:39:46 <Kevin_Kofler> (see the previous meeting point)
19:39:51 <pjones> nirik: seems about right
19:40:07 <Oxf13> Kevin_Kofler: that's probably my fault, I didn't realize install_initrd was an lsb function
19:40:11 <nirik> ok, who will talk to tor maintainer, and who will talk to FPC?
19:40:21 <dgilmore> install_initd sounds like it should be a wrapper for chkconfig
19:40:24 * nirik tries to make sure this stuff gets followed up on. ;)
19:40:32 <skvidal> nirik: speaking of following up https://fedoraproject.org/wiki/FESCo/SuccessionPlanning
19:40:54 <nirik> I can update the bug for the tor maintainer if no one else wants to.
19:41:08 <nirik> skvidal: excellent.
19:41:11 <notting> dgilmore: it's a symlink.
19:41:44 <nirik> #action nirik will contact tor maintainer
19:41:56 <nirik> who wants to talk to FPC about scriptlet output?
19:42:08 <dgilmore> notting: :) we should ask fpc to give us a guideline then that says use chkconfig only and not install_initd just for clarity
19:42:12 <pjones> dgilmore: it actually parses lsb-only crap in the initscript and does shit based on it
19:42:34 <pjones> dgilmore: lsb basically re-implements sysv init scripts + chkconfig in its own wildly sillier way.
19:42:53 <nirik> and our current guidelines say they are not required, but can be used.
19:43:12 <pjones> right.  but we should be clear that that's about the stuff in the initscript, not the use of the associated shitty stupid tools.
19:43:13 <dgilmore> pjones: eww
19:43:17 <Kevin_Kofler> Yet our review guidelines say we should verify compliance of initscripts with the initscripts guidelines.
19:43:23 <Kevin_Kofler> (if I'm not mistaken)
19:43:54 * nirik notes we are coming up on 15min on this topic.
19:43:59 <ajax> compliance with the guidelines does not mean implementing all optional features.
19:44:03 <notting> dgilmore: note that chkconfig invoked as install_initd does change the behavior slightly
19:44:15 <Oxf13> question from the peanut gallery, how much of this "goes away" if/when we move to full upstart init style?
19:44:16 <notting> and i think that's enrico's bug. install_initd is actually enforcing the standard.
19:44:33 <notting> Oxf13: oh, i suspect we'll get an entirely different set of issues then.
19:44:40 <nirik> "LSB Headers are not required for Fedora SysV-style initscripts, but they may be used. There is no requirement in the LSB certification for any system scripts to be LSB compliant, and it can cause issues with ordering."
19:45:36 <nirik> no takers on talking to FPC about scriptlet output?
19:45:40 <ajax> i really don't want to have to cite rfc2119 in the guidelines, but, here we are.
19:45:44 <ajax> nirik: i'll do that.
19:45:51 <nirik> hurray.
19:46:02 <nirik> #action ajax will talk to FPC about scriptlet output
19:46:16 <nirik> #topic #355 Let rel-eng untag embryo from F-13 because it breaks the chain and upgrade path
19:46:21 <nirik> .fesco 355
19:46:23 <zodbot> nirik: #355 (Let rel-eng untag embryo from F-13 because it breaks the chain and upgrade path) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/355
19:46:27 <nirik> cwickert: just updated this
19:46:49 <nirik> so, I am happy with waiting a week to give them a chance to fix it.
19:46:54 <pjones> I think we should probably untag this, since people may have it installed but they certainly can't be /using/ it.
19:47:10 <Oxf13> yeah, it's extremely unlikely they would have installed it
19:47:12 <mjg59> pjones: But if they've managed to get it installed, updates will then be broken?
19:47:13 <Oxf13> let alone use it
19:47:18 <Kevin_Kofler> Untagging without an Epoch bump means making the version go backwards.
19:47:29 <nirik> please read the last comment in the ticket.
19:47:35 <Kevin_Kofler> So it has been suggested that they should just bump Epoch.
19:47:40 <Oxf13> Kevin_Kofler: which is only really a problem if it's actually been on somebody's system.
19:47:47 <cwickert> IMO this really is a social problem
19:47:48 <Kevin_Kofler> But maybe upgrading the whole stack instead would be the better solution.
19:47:51 <thomasj_> Nobody will have it installed. It's only used for Enlightenment.
19:47:54 <cwickert> cassmodiah, can you comment on this?
19:47:59 <Kevin_Kofler> It's already done in Rawhide, it just needs to go into F13.
19:48:16 <mjg59> Oh, fine
19:48:19 <mjg59> Just leave it for a week
19:48:22 <notting> Kevin_Kofler: ok then. go forth and do, etc.
19:48:31 <ajax> +1 to defer for a week
19:48:41 <Kevin_Kofler> Well, actually it's not complete in Rawhide yet.
19:48:44 <notting> +1 to defer
19:48:49 <dgilmore> -1 to untagging the build
19:48:51 <pjones> Kevin_Kofler: no, putting in a new package reusing the old VR makes the version go backwards.  either way, I'm +1 to defer.
19:48:54 <cassmodiah> i think 1 week isn't enough. I'm currently not briefed
19:48:57 <cwickert> +1, give them a week to fix ot. not a fesco thing IMO
19:49:03 <nirik> +1 to waiting and revisiting
19:49:06 <Oxf13> thomasj_: do not underestimate the ability for our users to do silly things we never expect them to do (:
19:49:07 <cwickert> cassmodiah, che will help you
19:49:18 <pjones> mjg59: updates wouldn't be broken so long as the next version is still newer than the broken one (i.e. release=2 or whatnot.)
19:49:34 <Kevin_Kofler> I'm a bit worried about the schedule for doing an update of the whole E17 stack for Rawhide now.
19:49:39 <skvidal> +1
19:49:42 <cassmodiah> cwickert i hope that this help isn't too late! :-/
19:49:43 <thomasj_> cwickert, by the way, thanks for the social comment. I will bring it up again later in a different discussion.
19:49:55 <thomasj_> Oxf13, you're right ;)
19:49:59 <cwickert> thomasj_, welcome
19:50:13 <dgilmore> We have in the past refused requests like this
19:50:23 <Kevin_Kofler> pjones: The point is, it will not be! The proposal is to revert to an old build without an Epoch bump.
19:50:25 <Oxf13> dgilmore: we have when it was already on people's systems
19:50:35 <dgilmore> I think we need to be consistent and have them fix the issue in the packaging
19:50:44 <Oxf13> the way I see it, currently nobody can install/test E stuff
19:50:52 <pjones> Kevin_Kofler: right, but that doesn't matter as long as there's another update /after that/ that fixes the problem and has a newer VR than the broken one.
19:50:52 <thomasj_> yep
19:50:56 <Oxf13> so we could gain back a week of some limited testing by untagging
19:50:57 <dgilmore> Oxf13: there is no reason that they cant just build a new nvr
19:51:12 <dgilmore> the latest tagged package will win
19:51:12 <thomasj_> Oxf13, and if the new packages go into F-13 it is untested.
19:51:13 <pjones> Kevin_Kofler: the people with a broken version already will remain affected, it's true, until there's a Real Fix.
19:51:15 <Oxf13> then when everything is ready to go to the newer stuff, we can re-tag, or get a new build.
19:51:16 <cwickert> Oxf13, the old stuff was tested and used for two years now
19:51:32 <pjones> Oxf13: yeah, that's what I'm seeing
19:51:38 <Kevin_Kofler> dgilmore: That's also against the same "the branch should not go backwards" rule though.
19:51:40 <Oxf13> cwickert: which doesn't mean it will work with the rest of F13
19:51:46 <cwickert> true
19:52:00 <Oxf13> so the real question here, to me, is how important is that week~ of testing?
19:52:03 <Kevin_Kofler> And it has no real advantage over just untagging the newer unwanted build.
19:52:06 * thomasj_ want's the old stuff in F-13 for now, that's why i asked rel-eng to untag it.
19:52:10 <Oxf13> are the E folks OK with it being impossible to install for a while?
19:52:26 * thomasj_ thinks it's better to have the new stuff tested first
19:52:38 <nirik> an addition week of testing the already known stable one doesn't seem to usefull.
19:52:38 <cwickert> Oxf13, I guess, it's already broken for weeks and nobody complained
19:52:54 <nirik> but it does mean that new users can't install it for now.
19:53:01 <Kevin_Kofler> thomasj_: If you want the old stuff in F-13, then bump Epoch.
19:53:15 <Oxf13> Kevin_Kofler: that's completely unnecessary
19:53:18 <nirik> (and in rawhide as well to preserve upgrade path)
19:53:23 <cwickert> I think this can be fixed within one or two days, if all people work together
19:53:25 <thomasj_> Kevin_Kofler, i can do that as well. cwickert told me to ask rel-eng
19:53:28 <Kevin_Kofler> nirik: Right.
19:53:49 <thomasj_> Kevin_Kofler, and rel-eng said they need the ok from FESCo there.
19:53:53 <nirik> so, we have enough votes to defer and revisit, shall we just do that and move on?
19:53:56 <Oxf13> how about we actually look past the words of a rule, and try to understand the /reason/ for the rule
19:54:00 <cassmodiah> cwickert +1 this can be fixed soon, if there is any teamwork
19:54:08 <Kevin_Kofler> Oxf13: Isn't the current policy that Rawhide should never go backwards, let alone branched releases?
19:54:16 <Kevin_Kofler> I don't care all that much about that policy.
19:54:26 <Kevin_Kofler> But if we don't want to enforce it, why do we have such a policy at all?
19:54:41 <Oxf13> Kevin_Kofler: such a policy exists yes, to protect users from being left out in the cold if the package they have installed goes backwards
19:54:48 <Kevin_Kofler> (FWIW, I think Rawhide or unreleased releases going backwards is not a big problem.)
19:54:50 <Oxf13> in this case, it is extremely unlikely anybody actually has this package installed
19:55:00 * nirik does. ;)
19:55:00 <Oxf13> /and/ there would be a newer n-v-r coming soon, after testing
19:55:29 <cwickert> Oxf13, they *cannot* install the package because it's broken/the broken deps prefent people from installing it
19:55:33 <Oxf13> untagging may break the words of the rule, but certainly not the spirit or reason for the rule.
19:55:39 <notting> if it's going to be fixed soon, just fix it
19:55:40 <Oxf13> cwickert: that's... not true
19:55:47 <nirik> cwickert: not true. You can install it by itself. You can't install it with any of the rest of the stack
19:55:49 * cwickert looks...
19:55:53 <abadger1999> cwickert: .... they could have installed embryo without the other deps.
19:56:00 <mjg59> Do we need to discuss this any further?
19:56:01 <thomasj_> yep
19:56:06 <thomasj_> oh, yep to abadger1999
19:56:23 <dgilmore> mjg59: nope we need to say that it cant be untag and needs fixed within the packaging
19:56:23 <nirik> I guess we have votes to defer and revisit...
19:56:24 <cwickert> I doubt that anybody has installed it embryo, it's not in comps, it's a lib
19:56:40 <thomasj_> Yep
19:56:45 <Oxf13> cwickert: right, which is why I said it's highly unlikely, but not impossible.
19:56:54 <cwickert> ok then Oxf13
19:57:05 <nirik> I have it installed... because I was curious about it... others might have installed it due to our dicussions?
19:57:14 <Kevin_Kofler> Well, the lead Release Engineer says we should just untag this.
19:57:25 <mjg59> But we've also decided that we can leave it for a week
19:57:31 <Kevin_Kofler> So IMHO we should do as he said.
19:57:42 <Oxf13> untagging would actually be better than leaving it for a week and waiting for a fix
19:57:50 <Kevin_Kofler> His arguments make sense.
19:57:51 <pjones> yeah, I'm with Oxf13 here
19:57:51 <Oxf13> untagging would allow people who want to install E to actually be able to
19:58:00 <mjg59> Oxf13: Ok, fine, utterly happy to defer to you on this
19:58:17 <pjones> right.  people with it already installed will have a broken one, but everybody else avoids damage.  untagging is best.
19:58:17 <Oxf13> the time to fixed package doesn't really change here.
19:58:25 <cwickert> +1 for untagging, but rel-eng closed the untag request WONTFIX
19:58:34 * notting defers to Oxf13, then. +1 to untag
19:58:39 <mjg59> +1 for untagging
19:58:42 <dgilmore> anytime something like this has come up we have consistently said if it has been pushed to rawhide(i.e. any repo really)  it can not be untagged and needs to be fixed via a epoch if it must go backwards
19:58:45 <Kevin_Kofler> +1 to untagging (and we can reopen the rel-eng request)
19:58:47 * nirik shrugs. I don't much care except that we might get more people with diffrerent issues asking us to untag things.
19:58:49 <pjones> +1 for untagging since I've said that like 50 times now.
19:58:58 <notting> cwickert: rel-eng was not going to break policy to untag w/o fesco approval, as i understand it
19:59:06 <dgilmore> there is a reason we ahve always said no to untagging
19:59:07 * skvidal is with nirik - having  hard time caring
19:59:09 <Oxf13> dgilmore: the reason behind that is to protect people who have potentially installed it.
19:59:10 <cwickert> notting, i see
19:59:12 <ajax> 0, don't care, just make it go away.
19:59:17 <Oxf13> dgilmore: please please read past the bare words of the rule.
19:59:20 <skvidal> ajax: I like this answer
19:59:23 <dgilmore> Oxf13: right and people may have in this case also
19:59:26 <mjg59> I think we're done
19:59:32 * nirik tallys
19:59:37 <pjones> dgilmore: right, but not untagging it doesn't protect them any in this case
19:59:37 <dgilmore> Oxf13: at least nirik has it installed
19:59:46 <mjg59> Especially as we'll be at 15 minutes in 2 minutes
19:59:50 <cwickert> untag and revisit next week (if still necessary)
19:59:57 <cwickert> period
20:00:08 <nirik> #agreed FESCo will allow releg to untag this package for now, revisit this next week if there are still issues.
20:00:14 <mjg59> Full stop carriage return carriage return THE END
20:00:18 * dgilmore is going to leave the meeting now
20:00:19 <mjg59> Ok
20:00:28 <thomasj_> Thank you.
20:00:28 <nirik> #topic #348 Fedora Packaging Committee items for ratification (2010-02-24)
20:00:38 * nirik sighs
20:00:40 <Oxf13> untagged.
20:00:46 <mjg59> Does anyone have any arguments against these proposals?
20:00:54 <nirik> .fesco 348
20:00:54 <ajax> nope.
20:00:55 <zodbot> nirik: #348 (Fedora Packaging Committee items for ratification (2010-02-24)) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/348
20:00:58 <pjones> I vote we rubber stamp these with great force.
20:01:08 * skvidal waits for it
20:01:19 <ajax> i say your three cent titanium tax doesn't go too far enough.
20:01:29 <ajax> +1
20:01:30 <nirik> should we do them one at a time?
20:01:31 <cwickert> +1 to all of them
20:01:44 <mjg59> nirik: Unless anyone has any arguments against, no real point
20:01:49 <nirik> true.
20:01:49 * notting is +1 to both
20:01:51 <nirik> +1 to both
20:01:52 <mjg59> Both seem sane, so I'm +1 to both
20:02:00 <Kevin_Kofler> Wait a minute…
20:02:00 <pjones> looks like 5.
20:02:01 <skvidal> +1 to both
20:02:06 <Kevin_Kofler> About the "Add a Dummy Macro" part.
20:02:16 <Kevin_Kofler> Can we not just mass-change all the packages instead?
20:02:30 <mjg59> Kevin_Kofler: My recollection is that one of the font maintainers was unhappy about doing so
20:02:46 <Kevin_Kofler> That's what we have provenpackagers for.
20:02:56 <nirik> Kevin_Kofler: there are also still font packages that don't use the current guidelines.
20:02:56 <Kevin_Kofler> But I'm +1 to both guideline changes.
20:02:58 <mjg59> And while we could mandate that, the packaging committee have found a mechanism that doesn't require it
20:03:20 <mjg59> So, while it's not ideal, it's also not obviously damaging
20:03:20 <pjones> yeah, I think the reason for the dummy macro is really that we expect packages to lag behind the guidelines, if only slightly.
20:03:28 <ajax> i would certainly prefer that all the font packages be updated, but i'm not going to insist on it this week.
20:03:30 <nirik> #agreed Both guidelines changes are accepted.
20:03:36 <skvidal> next!
20:03:46 <nirik> #topic Fedora Engineering Services Tickets/Updates.
20:03:56 <nirik> I don't have much to report here, so I am not going to go over them all.
20:04:04 <nirik> There is steady progress on most of the larger ones.
20:04:11 <nirik> mmcgrath: you have anything to note?
20:04:33 <mmcgrath> Nothing major, incremental progress from last week.  I got a few broken deps fixed
20:04:47 <mmcgrath> For the most part though it seems most of the broken deps are actually known by the packagers.
20:05:05 <nirik> cool.
20:05:08 <mmcgrath> It's just the fix sometimes requries work from upstream.
20:05:12 <mmcgrath> so generally things are good.
20:05:29 <nirik> if anyone would like to join in and help things, follow the wiki page...
20:05:37 <nirik> if anyone has additional tickets to work on, file away.
20:05:41 <nirik> thanks mmcgrath
20:05:47 <nirik> and now the fun part. ;)
20:05:52 <nirik> #topic #351 Create a policy for updates
20:05:56 <nirik> .fesco 351
20:05:57 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351
20:06:10 <nirik> notting made a number of changes last week.
20:06:27 <notting> yeah, i made some changes after talking with QA
20:06:30 <nirik> Kevin_Kofler has some amendments to discuss.
20:06:42 <nirik> https://fedoraproject.org/wiki/UpdatePolicy(draft)#notting.27s_Proposal
20:06:48 <notting> if it makes things simpler, we can vote on each of the three segments separately
20:06:51 <nirik> can everyone take a minute to just re-read the proposal?
20:06:54 <notting> they stack on top of each other, more or less
20:07:30 <adamw> quick note: QA is still working on a policy to document the whole process of how updates are actually managed
20:07:33 <Kevin_Kofler> FWIW, I'm also still -1 to the proposal as a whole, even amended, as I don't see a need for such a policy at all.
20:07:41 <wwoods> ...
20:08:10 <Kevin_Kofler> But if the policy is taken as a given, then let's at least get my amendments to a vote (and hopefully approve them).
20:08:12 <pjones> Kevin_Kofler: can we just take that as a given from here on out?
20:08:21 <adamw> since last week's meeting didn't show much enthusiasm for merging it with notting's policy on update requirements during the draft phase, and notting said he'd prefer to work on his update requirements document just as it is for now, i'm trying to nudge the broader QA proposal in the direction of being a 'shell' into which notting's update requirements document would plug
20:08:49 <pjones> adamw: sounds backwards.
20:08:50 <adamw> so fesco could approve notting's requirements policy and then consider the broader process policy whenever we're done drafting it, and the agreed requirements policy would not need to change
20:09:39 <adamw> pjones: how do you mean?
20:09:58 <jlaska> pjones: notting's proposal focuses on package acceptance criteria, which is what QA is hoping to get consensus on so we can refine https://fedoraproject.org/wiki/User:Kparal/Proposal:Package_update_acceptance_test_plan
20:10:26 <pjones> jlaska: yes, but wedging something else around it later sounds unlikely to produce fruitful results
20:11:04 <nirik> so, how should we move forward here? shall we discuss Kevin_Kofler's amendments first? or decide we want more QA buyin of nottings proposal in general before voting?
20:11:09 <adamw> pjones: i don't think it's particularly tricky, we just yank the stuff about specific requirements out of the draft we had last week, and instead link into notting's policy when saying what the actual requirements to move from step to step are
20:11:49 <nirik> adamw: so, nottings proposal would be a subset of the overall updates qa flow?
20:11:53 <notting> nirik: i'd like to offer up section 1 for a vote first. i would think it's the least controversial, and Kevin didn't have an amendment to it
20:12:01 <nirik> ok.
20:12:22 <nirik> I have a question. ;) Point 4.... is that taking into account multilib? ;)
20:12:36 <adamw> nirik: right. and if we never manage to agree on a policy to cover the whole process, notting's policy on requirements can still stand alone. so i think the approach is fairly safe.
20:12:39 <notting> nirik: sure.
20:12:48 <Oxf13> fwiw, from a releng pov, section 1 is very good
20:12:59 <nirik> so, packages with broken multilib would fail and be unable to push as updates?
20:13:04 <notting> nirik: the overriding theme of those requirements is DON'T BREAK THE REPO
20:13:07 <Oxf13> in fact, it's the type of thing I plan to put as a barrier of entry to /any/ published Fedora package collection
20:13:15 <Oxf13> eg rawhide, branched, etc...
20:13:28 <nirik> in any case thats nitpicking. I'm +1 for section 1.
20:13:32 <pjones> adamw: I don't think you're necessarily wrong.  I do think we shouldn't discuss this until after we've /got/ a policy ratified.
20:13:48 <Kevin_Kofler> +1 to section 1, that's something that sounds obvious even to me. :-)
20:14:10 <Kevin_Kofler> (and it's pretty much why AutoQA is being developed in the first place)
20:14:40 <nirik> ok, thats +1
20:14:44 <nirik> +2 rather
20:15:02 * notting is +1, obvs.
20:15:03 <mjg59> +1
20:15:04 <Kevin_Kofler> Though maybe "Packages must not break upgrade path" should be clarified to ensure that it's possible to queue the same update to multiple releases at the same time.
20:15:05 <abadger1999> Question on scope: Does this section (or the whole policy) cover updates only or updates + updates-testing?
20:15:06 <cwickert> +3 at least ;)
20:15:09 <adamw> pjones: yeah, no, i agree, at this meeting, just discuss notting's proposal. i just wanted to make sure the fate of QA's proposal was on the record in case anyone wondered where it had disappeared to after last week =)
20:15:30 <nirik> abadger1999: see the bottom of that section.
20:16:04 <nirik> "As a discussion point, some subset of these tests could be run on pending updates, and the results used to block updates going to updates-testing as well."
20:16:09 <pjones> what, precisely, is being voted on?
20:16:21 <nirik> pjones: https://fedoraproject.org/wiki/UpdatePolicy(draft)#notting.27s_Proposal
20:16:21 <notting> pjones: section 1 of the proposal.
20:16:22 <abadger1999> ah... so pending updates are updates in updates-testing, not updates that are pending in bodhi...
20:16:23 <nirik> section 1
20:16:27 <pjones> +1 to section 1 then
20:16:42 <nirik> abadger1999: yeah, I guess thats confusing...
20:16:42 * skvidal +1's section one
20:17:00 <nirik> #agreed Section 1 of the proposal is approved.
20:17:08 <nirik> next section.
20:17:08 <ajax> +1 to section one (late)
20:17:14 <Oxf13> Kevin_Kofler: re multiple updates at the same time, lets leave that for implementation
20:17:24 <notting> ok, section 2. Kevin_Kofler has an amendment to this section.
20:17:29 <adamw> section 1 lists whether the tests should be applied to updates-testing as a 'discussion point'
20:17:32 <adamw> was that settled yet?
20:17:50 <mjg59> adamw: Given that we've already voted on it, can we please delay discussion until later?
20:18:01 <nirik> adamw: no. We could discuss adding that after?
20:18:21 <adamw> nirik: sure, so for now it's unsettled.
20:18:26 <nirik> adamw: yep. ;)
20:18:33 <notting> i'm not in favor of Kevin_Kofler's amendment, as rather than "ensur[ing] the SIGs controlling the desktops can make autonomous decisions about when to push updates to their desktops without being reliant on external groups such as QA.", i'd prefer the SIGs work with and within QA
20:18:54 * skvidal is -1 to the amendment, too
20:19:14 <Kevin_Kofler> Can we at least seed the initial list with at least 1 member of each desktop's SIG until we have more of it?
20:19:16 <mjg59> Wait
20:19:17 <nirik> I would also be -1, but I would hope the criteria to be a proventester would allow anyone from those SIGs who already does testing to be able to have that status
20:19:17 <Oxf13> where is this amendment ?
20:19:24 <mjg59> Are we voting on the amendment, or the amended proposal?
20:19:26 <nirik> Oxf13: in the ticket.
20:19:33 <ajax> Oxf13: https://fedorahosted.org/fesco/ticket/351#comment:12
20:19:52 * nirik thought we were voting on the amendment. Should we vote on the proposal first?
20:19:56 <Kevin_Kofler> I'd nominate rdieter for KDE, he's done that "job" as a rel-eng member for pending releases so far and he did it well (even for non-KDE packages).
20:19:58 <mjg59> And, given the constraints Kevin imposed, are we looking at section two or section 3?
20:20:07 <skvidal> I think we are looking at
20:20:08 <skvidal> Amendment proposal C: In section 2, codify that the group of testers empowered to give the magic karma needs to include at least 1 member (or in the event the criteria get changed to require some karma n rather than 1, n members) of each SIG behind one of the desktops considered "critical" by section 2.
20:20:08 <skvidal> Rationale: This ensures the SIGs controlling the desktops can make autonomous decisions about when to push updates to their desktops without being reliant on external groups such as QA.
20:20:16 <mjg59> nirik: It's generally faster to just vote on the amended proposal
20:20:19 <adamw> for information, the current proposal for having people become 'proven testers' is http://lists.fedoraproject.org/pipermail/test/2010-February/088824.html . it's still heavily under discussion, though
20:20:22 <mjg59> nirik: That way you don't need to have a second vote if it passes
20:20:45 <Oxf13> fwiw, as an outsider, I'm also against that amendment.
20:20:50 * gholms|mbp rings the 15 minute bell
20:20:52 <Oxf13> to date, we do not have any criteria for the proventesters group
20:21:11 <nirik> yeah, 15min. ;) Shall we continue? votes?
20:21:13 <nirik> +1 here
20:21:14 * cwickert would like to give this another 15 minutes
20:21:15 <pjones> adamw: please stop injecting confusion to this discussion.  it is not helping.
20:21:16 <mjg59> Continue
20:21:16 * notting is +1 to continuing discussion
20:21:18 <Oxf13> therefor the amendment text would be better served on the proposal for the proventesters group composition
20:21:19 <skvidal> +1 to continuing
20:21:27 <pjones> I think we should continue.  What's the url for kevin's amendment?
20:21:34 <Oxf13> leaving the updates policy to just reference the proventesters group
20:21:40 <nirik> pjones: https://fedorahosted.org/fesco/ticket/351#comment:12
20:21:49 <adamw> pjones: it was in response to nirik's question about the criteria to be a proven tester. i thought that in context it would be fairly helpful for nirik to see what the discussion about those criteria was.
20:21:52 <pjones> Oh, it's on the ticket.  how interesting.
20:22:16 <nirik> I would hope that sigs/desktops/important app/critical path using people would be able to become proventesters.
20:22:29 <Oxf13> they should be
20:22:30 <adamw> nirik: at present i think that's very likely to be the case. oxf13 would you agree?
20:22:31 <nirik> especially those people who already do that kind of testing for their sig/app/desktop/etc
20:22:49 <nirik> ie, if KDE has some folks who do a lot of their testing, I would hope they would be able to get this status...
20:23:00 <Oxf13> proventesters would be in line with provenpackagers, no real restrictions on who can join, just a criteria to meet and peer approval
20:23:03 <nirik> so, no need to mandate it.
20:23:25 <nirik> Kevin_Kofler: would that meet your concerns?
20:23:49 <Kevin_Kofler> I guess it would.
20:23:56 <nirik> so, any other general comments on section 2?
20:24:03 <Oxf13> but again, any sort of verbiage about who makes up the 'defined group of testers' should go in the proposal and policy for proventesters, not in the update policy
20:24:12 <nirik> notting: we don't have a current list do we?
20:24:28 <notting> nirik: list of...?
20:24:41 <nirik> notting: 'important packages'
20:24:52 <Kevin_Kofler> Other than that I don't see the need for such added bureaucracy at all? :-) (But section 3 is the worst.)
20:25:03 <notting> there is the critical path list. we can, if people want, expand the definition of critical path as described
20:25:08 <nirik> Kevin_Kofler: we will get to 3 next. ;)
20:25:13 <wwoods> Kevin_Kofler: think we agreed to take that objection as a given.
20:25:16 <nirik> http://kojipkgs.fedoraproject.org/mash/branched-20100316/logs/critpath.log
20:25:18 <notting> in which case, it's just a matter of tweaking the tools that create that llist
20:25:27 <abadger1999> Is there a rationale for  having two separate lists (critpath and non-critpath important packages).
20:25:38 <nirik> notting: ok, but it currently doesn't have KDE/LXDE/XFCE in it. ;)
20:25:45 <adamw> i thought the original reason we came up with critpath in the first place was to feed into a policy like this
20:25:46 <nirik> abadger1999: which is?
20:25:53 <Oxf13> for the sake of the proposal at this time, I think section 2 lists enough package names in addition to critpath
20:25:59 * nirik notes that still has the xfce4-notifyd thing in it.
20:26:12 <cwickert> nirik, this is a yum problem
20:26:14 <adamw> so it would seem a bit odd to have critpath exist and then be expanded when we actually use it. would we actually use the non-expanded critpath list for anything?
20:26:15 <notting> abadger1999: only that critpath is not currently defined for the other desktops, and i think this proposal should cover them
20:26:22 <wwoods> there's definitely rationale for having multiple layers above critpath; section 2 seems to be defining one of those layers
20:26:35 <abadger1999> notting: In that case, I'd rather see critpath expandedtoo voer them instead.
20:26:38 <Kevin_Kofler> That's also something kinda weird: Why would those be critical for updates, but not for new releases?
20:26:39 <wwoods> no.
20:26:49 <skvidal> cwickert: a yum problem?
20:26:50 <Oxf13> .... and we're getting lost in teh weeds
20:26:51 <Oxf13> look
20:26:57 <notting> ok, duly noted... separate proposal:
20:27:02 <Oxf13> does it really matter if the packages are 'critpath' or "critpath + some other stuff' ?
20:27:03 <abadger1999> * expanded to cover them
20:27:06 <Oxf13> that's not the real issue here
20:27:06 * nirik thinks this is a sort of implementation detail.
20:27:10 <skvidal> yes
20:27:12 <Oxf13> nirik: very much so
20:27:13 * notting redacts his typing
20:27:15 <abadger1999> Oxf13: Implementatoin wise, yes.
20:27:23 <mjg59> I'm +1 for section 2 as is
20:27:38 <Oxf13> abadger1999: for the sake of "does this policy make sense to work toward" it really doesn't matter.
20:27:41 <wwoods> "critpath" has a specific definition that (e.g.) does not include desktops other than the default. If you want to define another larger group that's a superset of critpath, that's an excellent idea
20:27:45 <mjg59> And now I'm going to find some caffeine
20:27:46 * notting is +1 for section 2 as written
20:27:49 <Kevin_Kofler> skvidal: It picks the notification daemon with the shortest name because the requirement is intentionally not specific.
20:27:55 <abadger1999> Oxf13: We can now modify critpath in the pkgdb... maintaining a second list for no reason means extra coding needs to be done in pkgdb and the mash driver script. bpodhi, etc
20:27:57 <cwickert> skvidal, right, both notification-deamon and xfce4-notifyd provide "desktop-notification-daemon" and this makes yum think that several xfce packages are critical path
20:27:58 <nirik> I'm +1 for section 2 and we can worry about the implementation details later.
20:28:11 <Kevin_Kofler> Not really a "problem" in yum, but in the way yum is being used to compute transitive closure here.
20:28:12 <Oxf13> abadger1999: again, not really important for today's meeting and today's vote.
20:28:15 <skvidal> cwickert: and how is that yum's fault - specify what you mean...
20:28:18 <pjones> nirik: likewise.
20:28:25 * skvidal is +1 for section 2
20:28:32 <cwickert> skvidal, problem != fault
20:28:34 <wwoods> (and if you want to use those newly-defined larger groups in various proposals/policies that's also excellent. but don't go throwing new things into critpath willy-nilly.)
20:28:44 <abadger1999> Oxf13: Are you going to write the bodhi and pkgdb and mash patches?
20:28:50 <mjg59> Ok, we're at 5 for section 2 as written
20:28:54 * nirik nods.
20:29:13 <cwickert> +1 for section 2
20:29:15 <mjg59> And we've got 30 minutes to get through section 3
20:29:16 <Kevin_Kofler> For the record: -1 to section 2, not needed.
20:29:17 <nirik> #agreed Section 2 is Approved. Implementation details will need to be worked out for listing/noting important packages.
20:29:36 <nirik> ok, on to section 3.
20:29:51 <Oxf13> abadger1999: not if the proposal doesn't get approved because we're too busy worried about the road signs 500 miles down the road and can't even get intot he car and start driving.
20:29:55 <mjg59> I'd like to propose that we firstly vote on section 3 as amended by Kevin's first proposal, ie the complete striking of section 3
20:29:55 <notting> Kevin's first amendment here i think can just be construed as a -1 vote on this section
20:30:09 <mjg59> To which I am -1
20:30:13 <Kevin_Kofler> Right, the first proposal is to strike it entirely.
20:30:23 <pjones> I'm -1 to striking section 3
20:30:29 <nirik> mjg59: you are -1 to not remove it? man, thats a lot of negativity. ;)
20:30:33 <Kevin_Kofler> The second one is to at least allow 1 proventester to approve stable pushes as for critical packages.
20:30:33 <abadger1999> Oxf13: How does having an accurate map before you get in the car sound like a bad idea to you?
20:30:51 <Oxf13> abadger1999: we've moved on, you should too.
20:31:07 * skvidal is -1 to striking section 3
20:31:12 * nirik is -1 to striking section 3.
20:31:20 <Kevin_Kofler> +1 to striking section 3, for the reasons given in the ticket.
20:31:29 * notting is -1 to pre-emtpively striking it
20:31:35 <skvidal> that's 5
20:31:37 <pjones> abadger1999: Oxf13 can you both quit it with the stupid metaphors?
20:31:59 <mjg59> I see that as -5 to striking section 3
20:32:07 * nirik nods.
20:32:18 <nirik> #agreed Section 3 will not be entirely removed.
20:32:32 <notting> at least, not yet. it may not pass a approval vote... ;)
20:32:37 <cwickert> +1 for section 3, just for the record
20:32:46 <Kevin_Kofler> (i.e. -1 to striking it? :-) )
20:32:47 <ajax> so.  on section 3.  "the[ir] specified positive bodhi karma threshold" is...
20:33:02 <notting> ajax: what the update maintainer specified on submission
20:33:06 <adamw> can that be 0?
20:33:12 * dgilmore proposes that new packages are not considered updates.
20:33:13 <notting> adamw: is 0 positive?
20:33:14 <nirik> 0 isn't positive
20:33:19 <ajax> 0 isn't positive (at least not in two's complement)
20:33:20 <adamw> i dunno, i took history, not math =)
20:33:35 <nirik> so, Kevin_Kofler has a amendment now for section 3.
20:33:35 * pjones votes adamw off the island
20:33:38 <skvidal> adamw: is 2000 or 2001 where the century turned over? :)
20:33:38 <adamw> (hence the question, now answered)
20:33:45 <pjones> skvidal: no.
20:33:53 <skvidal> pjones: it's a history question!
20:33:54 <skvidal> sorta
20:34:05 <notting> fwiw, i'm fine with considering Kevin_Kofler's amendment B here (in essence, that this proposal is not ever more strict than part 2)
20:34:05 <ajax> ANYWAY
20:34:07 <pjones> by which I both want you to STFU and also neither of those is when that event happened.
20:34:09 <Kevin_Kofler> The big problem with the first point of section 3 is: what if I want to not have the package automatically be pushed to stable when reaching the threshold, but have the option to push it?
20:34:15 * nirik is +1 for this amendment
20:34:26 <Kevin_Kofler> +1 for my own amendment, obviously. :-)
20:34:43 * notting is +1 for the amendment
20:34:43 <mjg59> Kevin_Kofler: Specify karma, don't specify automatically push?
20:35:03 <Kevin_Kofler> mjg59: Bodhi doesn't currently allow that.
20:35:05 <nirik> if we get a proventester to test the update, it should be no more strict than the 'important packages' section.
20:35:18 <mjg59> Kevin_Kofler: That's an implementation detail
20:35:22 <nirik> (or proventesters as the case may be)
20:35:29 <mjg59> Just to clarify:
20:35:38 <mjg59> Are we voting on the amendment, or are we voting on the amended proposal?
20:35:40 <dgilmore> mjg59: we are supposed to be working out the implementation
20:35:53 <ajax> amendment B does seem sensible, although i have trouble considering it different than submitting an update with threshold 1
20:36:12 <Kevin_Kofler> mjg59: Given that striking failed, it's pretty much the same.
20:36:15 <pjones> amendment b, though written in a terrible way that makes considering it unnecessarily difficult, does seem sensible.
20:36:22 * gholms rings the 30 minute gong
20:36:30 <mjg59> +1 to continuing discussion
20:36:38 <skvidal> +1 to continuing the argument
20:36:41 <nirik> +1 here
20:36:42 <mjg59> Kevin_Kofler: The latter potentially saves us a vote
20:36:46 <Oxf13> ajax: a threshold of 1 would mean it would automatically go when 1 is hit, instead of not being able to go until at least 1 is hit
20:36:54 <pjones> in the future, can we all try to write "section 3 should read <new language>" so we can tell what it's actually supposed to say?
20:36:54 <Kevin_Kofler> +1 to continuing discussion
20:36:54 <Oxf13> but this is a bodhi RFE, not a policy issue.
20:36:56 <cwickert> +1 for amendment b
20:36:57 <notting> +1 to watching skvidal and mjg59 debate whether it's a discussion or an arugment
20:36:58 <pjones> patches in english suck.
20:37:12 <cwickert> +1 for continuing the discussion
20:37:27 <nirik> mjg59: ok, we could just vote on the section as amended if you prefer.
20:37:30 <pjones> +1 to more mass confusion
20:37:42 <notting> so, while i proposed section 3, and think it's a good idea, i am concerned about the large number of packages that seem to be unable to find testers now
20:37:47 <nirik> +1 to section 3 as amended by Kevin_Kofler's amendment B
20:38:08 <Oxf13> notting: A) testing timeout.  B) Engineering Services ?
20:38:18 <nirik> notting: so, the 1 week timeout helps them?
20:38:21 <mjg59> Ok, I'm +1 to section 3 as amended
20:38:26 <adamw> notting: maybe reduce the time requirement? it would be nice to look at how long it usually takes before anyone files a -1 on a package, when people *do* file -1s
20:38:29 <ajax> ES doesn't really seem like QA for hire.
20:38:40 <adamw> if it never takes a week, then waiting a week is sort of unnecessary
20:38:45 <pjones> I think we need to actively recruit testers for individual packages if and when they're having trouble getting testers.
20:38:47 <dgilmore> FTR 2 weeks in testing works fine for EPEL
20:38:55 <skvidal> pjones: agreed there
20:38:58 <Oxf13> ajax: *shrug* I thought ES is what we make of it?  (not really a discussion for here/now though)
20:39:00 * nirik things we could get FES to make tools to get more testers
20:39:25 <nirik> well, it takes a while for a package to get out there...
20:39:38 <nirik> pushed one day, mirrored, someone has to update or install it, etc.
20:39:40 <Kevin_Kofler> dgilmore: 2 weeks is too long.
20:39:43 <notting> nirik: sure, but given the loud complaints from maintainers, i wonder whether it can be categorized as "one week is too long" or "any time is too long"
20:39:46 <Kevin_Kofler> 1 week is the maximum tolerable.
20:40:02 <notting> jwb: Oxf13: non-testing updates currently go out daily-ish, or...?
20:40:02 <Jeff_S> Ramereth: /win 24
20:40:06 <nirik> notting: we could setup a poll? :)
20:40:08 * Jeff_S hides
20:40:12 <Oxf13> notting: weekdayish
20:40:23 <adamw> I usually get -testing pushes around 12 hours after I see the mail hit the list, fwiw.
20:40:24 <Kevin_Kofler> Even 1 week is an annoyance.
20:40:35 <Kevin_Kofler> But 2 is just too frigging long.
20:41:13 <pjones> notting: so you're wondering if people will simply always complain?
20:41:21 <nirik> its a balancing act for sure...
20:41:28 <nirik> we can always adjust things.
20:41:35 <notting> pjones: i would like to both ensure we don't push broken things, while still honor their concerns where possible
20:41:41 <dgilmore> notting: 2 weeks is really not that long and i think is the amount of time we should mandate
20:41:51 <notting> i wonder if this should be considered in light of the board's update mandate
20:41:56 <pjones> so what we've really got isn't just a number for how much positive testing has happened, but also a confidence interval (which is unfortunately unmeasured)
20:42:02 <dgilmore> positive karma can always shorten it
20:42:08 <pjones> the question is, at a mere 5 days, how high can that confidence interval actually be?
20:42:20 <notting> pjones: 7 calendar, five-ish business
20:42:24 <nirik> yeah, if you want something faster, make it +1 and get one friend to vote on it (or currently, just the maintainer? )
20:42:27 <pjones> notting: question still remains.
20:42:36 <wwoods> I think it's worth considering the idea that nothing gets tested mostly because we don't require any testing
20:42:44 <Oxf13> wwoods: +1
20:42:52 <Kevin_Kofler> dgilmore: Most packages will never get positive karma, unless somebody gets nagged for it, which won't be the way to get real testing.
20:42:56 <pjones> anyway, I'm +1 on section 3 as amended
20:42:57 <wwoods> and that our ability to test stuff quickly - especially vitally important things - will change *rapidly* once it's actually required
20:43:08 <notting> wwoods: hm.
20:43:12 <ajax> +1 to section 3 plus amendment B.
20:43:13 <wwoods> people want new bits. If you tell them "you don't get new bits unless someone tests this package" someone's gonna test that package.
20:43:16 <nirik> we are at 4 +1's
20:43:17 <drago01> wwoods: might be true for "important" stuff but not for every package
20:43:27 <pjones> wwoods: that's what we're banking on really, yes.
20:43:29 <notting> can/should we amend these proposals with the notion that they will only apply to future releases?
20:43:42 <pjones> wwoods: though that rapid change may have to be facilitated by more action
20:43:46 <dgilmore> where is the amendment?
20:43:49 <nirik> notting: I think that may cause a lot of problems.
20:43:50 <mjg59> nirik: I think we're at more than +4
20:43:52 <Oxf13> drago01: I bet we'll see a lot more email posts with "can somebody quickly test this and give it karma"
20:43:56 <wwoods> drago01: I believe the current proposal only has hard requirements on the critpath (i.e. important) stuff?
20:43:57 <ajax> dgilmore: https://fedorahosted.org/fesco/ticket/351#comment:12 , for the third time.
20:44:09 <adamw> wwoods: well, we could certainly get people to sign on with getting the new bits from -testing. at that point, though, they have the bits. actually filing votes on the bits doesn't get them anything extra.
20:44:15 <dgilmore> ajax: this discussion is almost impossible to follow
20:44:23 <mjg59> I see notting, me, pjones, nirik, ajax
20:44:23 <pjones> notting: I don't think that's necessary since it really only makes hard requirements for critical path
20:44:39 <notting> mjg59: technically, i haven't +1'd this proposal yet
20:44:43 <mjg59> notting: Oh, sorry!
20:44:50 <notting> pjones: ... how so? part #3 applies to all other non-critpath updates
20:44:54 <dgilmore> section 3 as written by notting ill give a +1 to
20:44:54 <mjg59> That's why I was asking whether we were voting on the amendment or the amended proposal
20:44:58 <drago01> Oxf13: yeah but the "go hunt for testers" route isn't really a solution but well ...
20:45:03 <nirik> notting: ie, if we set this for f13 only, we will get a lot of newer NVR packages in older releases... and confuse maintainers.
20:45:06 <dgilmore> any of those amendments I cant accept
20:45:14 <Kevin_Kofler> What's wrong with amendment B?
20:45:21 <nirik> mjg59: yeah, thats since I said we were voting on the amendment + proposal.
20:45:25 <pjones> notting: well, in that we have not decided the specified amount of time...
20:45:33 <Kevin_Kofler> Why would we not allow a non-critical package to go out on the same rule a critical one can go out under?
20:45:55 <drago01> wwoods: I have no idea ... there are like ten proposals floating around
20:46:20 <notting> pjones: but the only amount of time to require that is compatible with current practice is zero
20:46:20 <nirik> current proposal: https://fedoraproject.org/wiki/UpdatePolicy(draft)#notting.27s_Proposal + amendment B from https://fedorahosted.org/fesco/ticket/351#comment:12
20:46:39 <pjones> notting: which is basically what we get until we decide on a time, AFAICS
20:47:00 <nirik> if we have no timeout, there will be little used packages that never get out of updates-testing.
20:47:23 * Oxf13 is curious what the meeting is waiting for
20:47:33 <Oxf13> there have been +5 votes on this
20:47:35 <nirik> at least one more +1 on the current proposal
20:47:38 <mjg59> Oxf13: Who?
20:47:53 <Oxf13> <mjg59> I see notting, me, pjones, nirik, ajax
20:48:02 <notting> Oxf13: i have not voted yet
20:48:02 <mjg59> notting confused me
20:48:04 <nirik> Oxf13: notting has not voted.
20:48:09 <Oxf13> oh, sorry, my bad.
20:48:24 <skvidal> Oxf13: wait - you voted?
20:48:27 * cwickert is hafing a hard time to follow. once "amendment" means nottings proposal, once it means Kevin_Kofler's suggestions
20:48:41 * Oxf13 notes that having it as a week now, and seeing where it goes, and can be adjusted later, isn't a bad way to do things.
20:48:47 <nirik> current proposal: Section 3 from https://fedoraproject.org/wiki/UpdatePolicy(draft)#notting.27s_Proposal + amendment B from https://fedorahosted.org/fesco/ticket/351#comment:12
20:48:50 <Oxf13> skvidal: I didn't vote, I copy/pasted mjg59's statement.
20:48:52 <adamw> cwickert: it's notting's proposal as amended by KK's Amendment B
20:48:54 <Kevin_Kofler> notting was +1 to just the amendment, but not to the combination of his own policy and the amendment?!
20:48:56 <dgilmore> -1
20:48:56 <drago01> skvidal: he copied mjg59's message ... so the "me" = mjg59
20:48:58 <skvidal> Oxf13: ah - I misunderstood
20:49:13 <notting> Kevin_Kofler: i was +1 to having the policy we consider be the amended policy
20:49:20 <notting> darned lack of context
20:49:22 <nirik> dgilmore: what are you reasons?
20:49:56 <mjg59> skvidal: Do you have an opinion?
20:49:59 <cwickert> nirik, +1 then, I thought we had already voted about this
20:50:06 <skvidal> at the moment I'm trying to piece together what I'd be voting FOR
20:50:18 <skvidal> i looked away to #yum for a few minutes and I've lost the thread
20:50:18 <cwickert> I though we were at section 3 of Kevin_Kofler's additions
20:50:26 <nirik> current proposal: Section 3 from https://fedoraproject.org/wiki/UpdatePolicy(draft)#notting.27s_Proposal + amendment B from https://fedorahosted.org/fesco/ticket/351#comment:12
20:50:37 <mjg59> skvidal: Section 3 of notting's proposal, as amended by Kevin's amendment B
20:50:39 <skvidal> okay
20:50:41 <nirik> skvidal: understandable.
20:50:42 <skvidal> so here's my take
20:51:10 <skvidal> kevin being in favor of this section with an amendment makes me think he sees a loophole in it and is going to try and play silly buggers
20:51:13 <dgilmore> nirik: i dont feel that the ammedndment gives anything more.  and is just added noise
20:51:14 * nirik notes another 15min are up. ;)
20:51:36 <Kevin_Kofler> Are we not at +5 already? mjg59, pjones, nirik, ajax, cwickert
20:51:37 <nirik> +1 to keep powering on. There's a light at the end of the tunnel.. I hope it's not a train.
20:51:39 <skvidal> so In general I'm -1 to the section with the amendment but I'm +1 to the section w/o the amendment
20:51:56 <mjg59> Ok, we're at +5
20:51:56 <Kevin_Kofler> skvidal: I'm not really in favor of either variant.
20:52:00 <notting> i just updated the wiki with the amendment included, basically.
20:52:13 <mjg59> HEALTH CARE FOR ALL
20:52:23 <notting> mjg59: +1 to that. oh wait.
20:52:27 <nirik> #agreed Section 3 + KevinK's Amendemnt B passes
20:52:37 <nirik> ok, so there are lots of implementation details here.
20:52:54 <notting> can we note that none of this is going live without work that is still to be done to bodhi, autoqa, etc?
20:52:57 <mjg59> I propose that we deal with those implementation details out of band
20:53:07 <nirik> notting: yeah.
20:53:11 <ajax> notting: quite.
20:53:14 <mjg59> Since it's going to involve working with the maintainers of everything involved
20:53:23 <pjones> yes.
20:53:26 <dgilmore> mjg59: why,  we are the body that iis tasked with working out the implementation
20:53:28 <nirik> #info None of this will take effect until implementation is made and announced and ready.
20:53:30 <mjg59> And then come back to it at a meeting once we have those hammered out?
20:53:46 <mjg59> dgilmore: Because we're constrained by the fact that the actual implementation of this involves volunteers who we have no direct control over
20:54:07 <mjg59> And certain issues may be constrained by implementation issues
20:54:09 <nirik> I think asking rel-eng/qa/infrastructure what it would take to implement and having them get back to us might be good.
20:54:21 <nirik> and we can decide further questions based on that...
20:54:27 <nirik> like if we need another important packages group
20:54:41 <nirik> or if maintainers can vote on their own updates
20:54:43 <nirik> or whatever.
20:54:51 <dgilmore> mjg59: we should work out how we want it implemented ask that it be done.  if its not possible those doing the implementation should report back and list what is possible
20:55:05 <notting> ok, so i'll write this up. where in the wiki namespace does this go?
20:55:27 <nirik> notting: under fesco policies I guess. Make sure it has a ! not yet implemented.
20:55:32 <pjones> dgilmore: that's a horrible way to write software.
20:55:39 <nirik> dgilmore: so should we task some subset of us to write a spec?
20:55:48 <dgilmore> nirik: no
20:55:52 <dgilmore> we should write the spec
20:55:57 <dgilmore> and ask it be implemented
20:56:21 <nirik> well, we have 5 minutes left in our meeting slot... how do we go about this?
20:56:28 <Oxf13> I thought the spec was just passed
20:56:40 <Oxf13> and now it's up to the software owners of the things which need to be modified to work from that spec and make it possible.
20:56:58 <mjg59> And where the spec contradicts reality, we discuss the issue further
20:57:03 <nirik> or come back and tell us that it's not or won't work
20:58:18 <ajax> nirik: i think we wait a week before moving any further.
20:58:18 <nirik> we should at least see who we have to ask here. bodhi will need lots of things... rel-eng scripts need any changes?
20:58:39 <ajax> in which time we'll probably think of a list of things that need addressing.
20:58:41 <nirik> ajax: for the flames to burn?
20:58:50 <ajax> well, that too.
20:59:01 * Kevin_Kofler rings the 1 minute until the end of the 2 hours bell. :-)
20:59:04 <nirik> ok, we can revisit next week and work on what we need to do.
20:59:05 <ajax> i was trying to be a little more utopian
20:59:07 <nirik> #topic Open Floor
20:59:08 <pjones> I'd like to propose that we table any more discussion today just because.
20:59:11 <Oxf13> all of this also needs autoqa to get in place, so....
20:59:12 <nirik> anything for open floor?
20:59:15 * gholms prepares the fireworks
20:59:40 <notting> i had a ticket i filed today with meeting tag, but it was probably too late
21:00:01 <skvidal> quick item
21:00:01 <gholms> Quick question:
21:00:03 <ajax> nirik: is it possible to get the meeting bot to give +v to the chairs?
21:00:03 <nirik> yeah, saw that, but the agenda was already pretty full.
21:00:13 <skvidal> when do we start the discussion for elections, etc? at the release?
21:00:16 <ajax> nirik: would make it a little easier to visually identify who's who.
21:00:28 <nirik> ajax: I don't think so, but I could do that as part of the startup process.
21:00:40 <pjones> that's a good idea.
21:00:53 <pjones> it also means we could change the mode on the channel when discussion gets too confusing.
21:00:57 <nirik> ajax: I will note it for next time.
21:01:10 <nirik> skvidal: https://fedoraproject.org/wiki/FESCo_election_policy
21:01:21 <gholms> Quick question:  If we end up getting working EC2 images up by release time should that make it into the release notes or features, or should such an announcement wait until F14?
21:01:29 <nirik> #info FESCo members will be voiced starting next meeting to help avoid confusion.
21:01:41 <skvidal> ok
21:02:22 <Oxf13> gholms: well, we're well past the feature freeze, so if you wanted it as a feature, you'd have to get an exception
21:02:41 <notting> gholms: if we get working images, i don't see why they can't be in the relnotes
21:02:58 <nirik> skvidal: I'm not sure who runs that process... but yeah, we might see about making sure it's dates are met, etc.
21:03:01 <gholms> Ok, that answers that question.
21:03:24 <nirik> I think inode0 ran things last time.
21:03:40 <gholms> If the meeting bot is going to voice people it'll need ops in every channel it regulates.
21:04:09 <nirik> gholms: the bot can't do that itself. It would need to be me or something.
21:04:17 <nirik> anything else? will close the meeting in a few.
21:04:40 <nirik> thanks for coming everyone!
21:04:45 <nirik> #endmeeting