=================================== #fedora-meeting: FESCO (2010-03-16) =================================== Meeting started by nirik at 19:00:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-03-16/fesco.2010-03-16-19.00.log.html Meeting summary --------------- * init process (nirik, 19:00:17) * #353 provenpackager request for walters (nirik, 19:02:24) * AGREED: walters approved for provenpackager (nirik, 19:05:07) * #352 Proposal: Fesco should have a procedure for removing members of fesco (nirik, 19:05:30) * 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. (pjones, 19:15:59) * #354 Desktop Spin size change should get a feature page (nirik, 19:18:36) * LINK: https://fedoraproject.org/wiki/Features/DesktopLiveImageTarget (nirik, 19:19:57) * LINK: https://fedoraproject.org/wiki/Features/DesktopLiveImageTarget (Kevin_Kofler, 19:22:05) * AGREED: This late feature is approved. Please finish up the page and add it to the right categories/lists. (nirik, 19:23:47) * #346 Drop LSB package (nirik, 19:24:17) * AGREED: This proposal is rejected. (nirik, 19:27:48) * AGREED: FESCo asks FPC investigate a guideline against direct dependencies on redhat-lsb (nirik, 19:29:57) * ACTION: notting will ask them to look into it. (nirik, 19:30:11) * #347 tor is not compliant with Fedora guidelines (nirik, 19:30:20) * AGREED: FESCo will ask tor maintainer to not use install_initd and will see if FPC can codify scriptlet output issues. (nirik, 19:39:25) * ACTION: nirik will contact tor maintainer (nirik, 19:41:44) * ACTION: ajax will talk to FPC about scriptlet output (nirik, 19:46:02) * #355 Let rel-eng untag embryo from F-13 because it breaks the chain and upgrade path (nirik, 19:46:16) * AGREED: FESCo will allow releg to untag this package for now, revisit this next week if there are still issues. (nirik, 20:00:08) * #348 Fedora Packaging Committee items for ratification (2010-02-24) (nirik, 20:00:28) * AGREED: Both guidelines changes are accepted. (nirik, 20:03:30) * Fedora Engineering Services Tickets/Updates. (nirik, 20:03:46) * #351 Create a policy for updates (nirik, 20:05:52) * LINK: https://fedoraproject.org/wiki/UpdatePolicy(draft)#notting.27s_Proposal (nirik, 20:06:42) * AGREED: Section 1 of the proposal is approved. (nirik, 20:17:00) * LINK: http://kojipkgs.fedoraproject.org/mash/branched-20100316/logs/critpath.log (nirik, 20:25:16) * AGREED: Section 2 is Approved. Implementation details will need to be worked out for listing/noting important packages. (nirik, 20:29:17) * AGREED: Section 3 will not be entirely removed. (nirik, 20:32:18) * AGREED: Section 3 + KevinK's Amendemnt B passes (nirik, 20:52:27) * None of this will take effect until implementation is made and announced and ready. (nirik, 20:53:28) * Open Floor (nirik, 20:59:07) * FESCo members will be voiced starting next meeting to help avoid confusion. (nirik, 21:01:29) Meeting ended at 21:04:45 UTC. -- 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
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
