=================================== #fedora-meeting: FESCO (2010-09-07) =================================== Meeting started by nirik at 19:30:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-09-07/fesco.2010-09-07-19.30.log.html .. Meeting summary --------------- * init process (nirik, 19:30:02) * cwickert unable to attend, but voted in tickets. (nirik, 19:30:41) * mclasen going to be a few minutes late. (nirik, 19:30:49) * #382 Implementing Stable Release Vision (nirik, 19:32:39) * ACTION: mjg59 and SMParrish to work on a problem description and some possible plans for kde updates. (nirik, 19:53:10) * #454 pre-release update acceptance criteria (nirik, 19:54:09) * cwickert voted in ticked on this item. (nirik, 19:54:24) * AGREED: proposal is accepted. (nirik, 19:58:57) * #455 gupnp-dlna bundled library exception (nirik, 20:00:28) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=617141 has notes from the gstreamer maintainer. (nirik, 20:01:11) * AGREED: exception granted (nirik, 20:04:02) * #459: FPC ratification: New bundled library draft (nirik, 20:04:23) * cwickert was +1 in the ticket here. (nirik, 20:04:48) * LINK: https://fedoraproject.org/wiki/Bundled_Library_Packaging_Draft (nirik, 20:04:52) * AGREED: will review and vote in the ticket or next week. (nirik, 20:08:13) * #456 Respond to split media naming bugzilla (nirik, 20:08:30) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=628695 (nirik, 20:08:48) * AGREED: This change is desired, but for f15 not f14. (nirik, 20:15:30) * #457 Bodhi changes for FESCo input (nirik, 20:15:44) * LINK: https://fedorahosted.org/bodhi/query?status=new&status=assigned&status=reopened&milestone=Need+FESCo+Approval&order=priority (nirik, 20:16:00) * cwickert also voted on these in ticket. (nirik, 20:16:08) * AGREED: no hard requirement on a bug for -karma (nirik, 20:19:48) * LINK: https://fedorahosted.org/bodhi/ticket/276 (nirik, 20:23:10) * AGREED: will not have negative karma block updates to stable. (nirik, 20:29:00) * need to gather info on how much of a problem this is. (nirik, 20:29:12) * LINK: https://fedorahosted.org/bodhi/ticket/294 (nirik, 20:30:18) * AGREED: This should be implemented. (nirik, 20:31:25) * LINK: https://fedorahosted.org/bodhi/ticket/277 (nirik, 20:33:05) * AGREED: update submitters should not be allowed to add or remove karma to updates they submitted. (nirik, 20:36:38) * http://fedoraproject.org/wiki/Features/DNSSEC_on_workstations (nirik, 20:37:14) * AGREED: ask questions and revisit next week. (nirik, 20:40:41) * http://fedoraproject.org/wiki/Features/GoldLinkerDefault (nirik, 20:42:32) * LINK: http://sourceware.org/bugzilla/show_bug.cgi?id=11805 is listed as fixed (notting, 20:44:21) * ACTION: ajax will ping tools folks about this. (nirik, 20:46:25) * AGREED: will revist next week (nirik, 20:47:13) * http://fedoraproject.org/wiki/Features/SetroubleshootGuiRedesign (nirik, 20:47:21) * AGREED: this feature is approved. (nirik, 20:49:02) * #460 FPC ratification: No Mandatory FESCo ratification (nirik, 20:49:26) * AGREED: the proposal is accepted. (nirik, 20:50:54) * Open Floor (nirik, 20:51:37) Meeting ended at 20:58:30 UTC. Action Items ------------ * mjg59 and SMParrish to work on a problem description and some possible plans for kde updates. * ajax will ping tools folks about this. Action Items, by person ----------------------- * ajax * ajax will ping tools folks about this. * mjg59 * mjg59 and SMParrish to work on a problem description and some possible plans for kde updates. * SMParrish * mjg59 and SMParrish to work on a problem description and some possible plans for kde updates. * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * nirik (167) * pjones (58) * mjg59 (37) * notting (36) * SMParrish (30) * ajax (27) * mclasen (21) * kylem (19) * zodbot (14) * lmacken (8) * belegdol (3) * kalev (1) * cwickert (0) -- 19:30:01 <nirik> #startmeeting FESCO (2010-09-07) 19:30:01 <zodbot> Meeting started Tue Sep 7 19:30:01 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:30:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:30:01 <nirik> #meetingname fesco 19:30:01 <zodbot> The meeting name has been set to 'fesco' 19:30:01 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59 19:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones 19:30:02 <nirik> #topic init process 19:30:41 <nirik> #info cwickert unable to attend, but voted in tickets. 19:30:48 * pjones is here 19:30:49 <nirik> #info mclasen going to be a few minutes late. 19:31:03 <mjg59> Here 19:31:17 * SMParrish here 19:31:21 <kylem> yo. 19:31:24 * notting is here 19:32:18 <nirik> ok, I guess lets go ahead and get going... 19:32:39 <nirik> #topic #382 Implementing Stable Release Vision 19:32:39 <nirik> .fesco 382 19:32:41 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382 19:33:01 <nirik> (I skipped #351 Create a policy for updates - status report on implementation since we are just waiting on autoqa there) 19:33:13 <nirik> any news to report on the docs work? or anything else related to this? 19:33:51 <nirik> ajax: have a chance to work on that doc anymore? 19:34:03 <ajax> not really, long weekend 19:34:44 <nirik> yeah, understandable. 19:35:14 <nirik> Would it be worth considering a special working session where we got as many of us as possible together to work on finishing out these items? 19:35:57 <ajax> *shrug* 19:36:17 * nirik would really like to complete this stuff... 19:36:34 <nirik> I guess I could work on the docs some in the coming week... 19:36:40 * SMParrish also wants to see this wraped up 19:37:08 <nirik> SMParrish: any news back from kde sig? 19:37:22 <kylem> i'll get my stuff wrapped up this week, it's been a busy summer. :< 19:37:35 <SMParrish> Yes, we had a long discussion about it today 19:38:47 <nirik> and what was the outcome? ;) 19:38:52 <SMParrish> Basically KDE will be asking for 1 exception per Fedora release for the major KDE bump. This will go into F(n)+ only. F(n-1) will only get security and bug fixes 19:39:20 <pjones> :( 19:39:26 <SMParrish> There is still much decension in the ranks but we will deal with that 19:39:31 <nirik> ok, with what reasoning? 19:39:53 <notting> (dissension, fwiw :) ) 19:40:11 <nirik> this would be like for f13 now, we have 4.4.5 and you would want an exception to push 4.5.x? 19:40:24 <SMParrish> Reasoning is that KDE's release does not match with Fedora's. Dont want people to have to upgrade to rawhide to enjoy the new KDE 19:40:39 <mjg59> Is it guaranteed that you'll be able to push KDE 4.x+1 without bumping Qt? 19:40:40 <SMParrish> nirik: Yes and for F14 for 4.6 etc 19:40:43 <notting> that seems contrary to the policy as written 19:41:02 <ajax> i liked the bit of that discussion where someone managed to say in nearly successive sentences that a) kde updates are stable so it's okay b) kde's stability in updates has gotten worse over time 19:41:11 <pjones> also several people here have expressed a preference not to do it this way - which casts doubt as to whether such exceptions would get approved 19:41:25 <SMParrish> notting: it is contrary which is why KDE will need an exception to push these updates 19:42:00 <mjg59> I'm certainly not going to say any definitive until we actually have a conversation on it 19:42:24 <mjg59> But I think that any kind of exception would be very tightly contingent upon a KDE update not requiring updates of any other systemwide components 19:42:40 <SMParrish> I know most of you use gnome and dont see why this is needed, but making people upgrade their systems to rawhide which is by definition unstable is not reasonable. 19:42:43 <nirik> right.... so this doesn't change anything in our implementation right? unless we wanted to always note in the policy that we would allow such an exception, which I think is a very bad idea. 19:42:44 <mjg59> So no new Qt, no new fontconfig, nothing like that 19:43:12 <mjg59> If it's limited to purely KDE components then it's an easier sell 19:43:20 <pjones> nirik: saying it there is a very bad idea indeed, especially seeing as we may well not 19:43:25 <SMParrish> mjg59: If anything else was needed the KDESIG will write up a formal proposal to bring to FESCo 19:43:29 * nirik nods 19:43:51 <mjg59> But I would also like to see us exploring ways of making it easier to provide updates like this as an optional channel 19:44:10 <pjones> mjg59: yes - as a separate layered repo would be significantly better. 19:44:31 <notting> SMParrish: false assumption that people are *required* upgrade to rawhide. not all may want a new version. 19:44:41 <SMParrish> mjg59: pjones I would be happy with a layered repo and think I can sell that to the SIG 19:44:48 <mjg59> One explicitly supported by the project and subject to more rigorous quality control than a random third-party yum repo 19:44:53 <notting> (sorry, unfucking the buildroot) 19:45:05 <pjones> SMParrish: I think that holds a whole lot more water than getting an exception every time to explicitly violate the policy 19:45:34 <pjones> (and provides the user with choice as well) 19:45:35 <mjg59> There's certainly no desire to prevent users getting updates if they want them, but we want to ensure that there's a supported distribution where people don't have to get those updates 19:45:38 <belegdol> kde-redhat exists already 19:45:42 <mjg59> And are still considered to be in a supported environment 19:45:49 <SMParrish> notting: Those who do not want it dont have to install it, but we want to provide it to those who do in an official Fedora repo 19:45:54 <pjones> belegdol: yeah, but it's not really the same thing as what we're talking about 19:45:59 <nirik> belegdol: sure, but that may be less 'official' looking than we want. 19:46:06 <notting> SMParrish: updates are functionally not optional 19:46:20 <pjones> nirik: also it's always the latest, as opposed to "the thing released right after fedora-$N" 19:46:29 <nirik> yeah. 19:46:34 <mjg59> SMParrish: The problem right now is that we don't have a way for people to receive all updates except KDE ones, and we don't have a way for the KDE SIG to provide security fixes for 4.4.x while also providing 4.5.x 19:47:11 <nirik> ok, we are at 15min or so now... votes to continue? Or shall we continue working on implementation and try and solve the kde update repo out of band? 19:47:16 <SMParrish> mjg59: And that is part of the problem as KDE does not issue security fixes for previous releases. 19:47:33 <SMParrish> So to get those fixes people need to be able to upgrade 19:47:37 <nirik> but you are supporting that version already... 19:48:03 * nirik is ok with a few more minutes, but also would be ok with going out of meeting... 19:48:12 <mjg59> SMParrish: Well, you've already said that you wouldn't ask for a further update in (n-1), so that's a problem that's going to have to be solved in any case 19:48:21 <SMParrish> nirik: Yes we are by pushing all KDE updates to all current releases 19:48:44 <mjg59> But yeah, I think we need to work out a precise problem description and work out the most acceptable solution 19:48:51 <mjg59> I'm happy to work on that 19:48:59 <SMParrish> mjg59: For F(n-1) the KDE sig can use kde-redhat if people want to use it, but we will suggest users upgrade to current Fedora 19:49:25 <mjg59> SMParrish: Uh. I don't think it's reasonable for the KDE sig to fail to provide security support to a supported version of Fedora. 19:49:59 <pjones> in fact, that sounds like a total package maintainer failure. 19:50:05 <SMParrish> mjg59: what choice do we have, upstream does not support those releases and neither RH Desktop team nor the SIG has the manpower or time to backport the fixes 19:50:09 <nirik> so if we updated f13 today to 4.5.1... f12 would still have 4.4.5 right? so, you are still having to support it. 19:50:25 <mjg59> SMParrish: If we can't provide security support then we can't provide the package 19:50:33 <mjg59> SMParrish: So we need to try to work something out where we do provide security support 19:50:45 <nirik> ok, votes to keep going? 19:50:49 <mclasen> SMParrish: I don't think we usually rely on upstream for security fixes 19:51:12 <notting> mclasen: well, we usually rely on upstream to fix *a* version, and then we either upgrade or backport 19:51:22 <mjg59> But anyway. Like I said, I'll write up my perception of the desirable qualities in a separate update channel (and this is something that'll apply beyond KDE) 19:51:26 <SMParrish> mclasen: KDE security fixes come out in a .x release we dont backport 19:51:30 <belegdol> on a related note, is anyone actually auditing old kde releases for security fixes? 19:51:40 <nirik> belegdol: what old kde releases? 19:51:52 <belegdol> the ones unsupported currently 19:51:55 <nirik> mjg59: if you could work with SMParrish and try and hash something out that would be great. 19:52:05 <nirik> belegdol: we don't currently have any of those. ;) 19:52:13 <mclasen> notting: my experience with security issues usually starts with a bug that I then have to write a patch for... 19:53:10 <nirik> #action mjg59 and SMParrish to work on a problem description and some possible plans for kde updates. 19:53:15 <nirik> sound reasonable? 19:53:20 <SMParrish> works for me 19:53:58 <nirik> any objections? moving on then... 19:54:09 <nirik> #topic #454 pre-release update acceptance criteria 19:54:10 <nirik> .fesco 454 19:54:11 <zodbot> nirik: #454 (pre-release update acceptance criteria) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/454 19:54:24 <nirik> #info cwickert voted in ticked on this item. 19:55:52 <mclasen> any questions on this ? I'll note that the topic came up on fedora-test-list in the meantime 19:55:57 <nirik> The main downside I see is maintainer confusion... 19:56:06 <nirik> as to what rules apply when. 19:56:14 <nirik> if we can document things well that might be ok. 19:56:30 <notting> mclasen: so, the big thing is the change from 7 days to 3? 19:56:55 <mclasen> I also reduced the karma threshold 19:57:03 <nirik> and +1 provenpackager only, no other votes needed. 19:57:16 <mclasen> but I think reducing the mandatory wait time is the bigger win 19:58:28 <notting> ok. seems reasonable. +1 from me 19:58:32 <pjones> +1 from me 19:58:39 <SMParrish> +1 as well 19:58:45 <kylem> +1. 19:58:46 <nirik> I'm ok with it provided we document it well. ;) +1 19:58:46 <mclasen> +1 from me too, obviously 19:58:52 <kylem> nirik, hehe. 19:58:57 <nirik> #agreed proposal is accepted. 19:59:00 <notting> with the obvious note that this is being changed for f15, not 'tomorrow' 19:59:08 <nirik> right. 19:59:22 <mclasen> I'll work with lmacken on the implementation and on the documentation update when things are ready 19:59:42 <nirik> mclasen: ok, I think docs for this could be folder in with the other docs we are trying to do for the updates vision too. 19:59:46 <nirik> folded 20:00:06 <nirik> anything else on this? or shall we move on? 20:00:28 <nirik> #topic #455 gupnp-dlna bundled library exception 20:00:29 <nirik> .fesco 455 20:00:30 <zodbot> nirik: #455 (gupnp-dlna bundled library exception) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/455 20:00:54 <nirik> looks like this is how gstreamer operates... 20:01:11 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=617141 has notes from the gstreamer maintainer. 20:01:43 <notting> given his comments, i'm ok with the bundling 20:02:02 <notting> better to bundle than to ship an API in the main gstreamer libs that might change when it actually lands upstream 20:02:09 <kylem> pretty much what i expected. 20:02:11 <nirik> yep. 20:02:16 <ajax> yeah, same. 20:02:18 <nirik> I'm ok with it as well... 20:02:23 * SMParrish agrees 20:02:29 <pjones> yeah 20:02:42 <mjg59> Yeah, I think this is entirely reasonable 20:02:43 <mclasen> +1 20:02:58 <kylem> indeed. 20:03:16 <nirik> ok, so: bundling is allowed as this code is heading actively for upstream and upstream wishes the project that needs it to bundle it until it's merged in the main upstream project with ABI stability? 20:03:29 <kylem> should we write up some kind of addendum to the policy so we don't need to grant exceptions in this style of issue? 20:03:49 <nirik> kylem: there's a new policy from FPC... we can look at that next. I suppose we should have before this. ;) 20:03:53 <kylem> nirik, yeah, that sounds reasonable. 20:03:55 <mclasen> this is not so much bundling, as staging, on some level 20:04:02 <nirik> #agreed exception granted 20:04:19 <nirik> mclasen: yeah. 20:04:20 <kylem> although, let's not make this overly broad so that people think we can add syscalls :) 20:04:23 <nirik> #topic #459: FPC ratification: New bundled library draft 20:04:23 <nirik> .fesco 459 20:04:24 <zodbot> nirik: #459 (FPC ratification: New bundled library draft) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/459 20:04:48 <nirik> #info cwickert was +1 in the ticket here. 20:04:52 <nirik> https://fedoraproject.org/wiki/Bundled_Library_Packaging_Draft 20:06:11 <pjones> is it just me or was this not in the agenda email yesterday? 20:06:23 <nirik> pjones: sorry, it was not... just added this morning. ;( 20:06:30 <pjones> oh right, I want to bring that up later. 20:06:36 <nirik> if folks would prefer pushing it out we can do that. 20:06:39 <pjones> _that's_ what I wanted to bring up later ;) 20:06:47 <mjg59> Typo in "recoll bundles unac but unac changed the API of unac", I think 20:06:58 <mjg59> By and large it seems sane, but I think we probably want more time 20:07:08 <pjones> yeah, I'd like some time to read through it 20:07:12 <nirik> ok, review and vote either in ticket or next week. 20:07:17 <nirik> ? 20:07:28 <mjg59> Yeah 20:07:46 <pjones> yeah 20:07:51 <SMParrish> yes 20:08:13 <nirik> #agreed will review and vote in the ticket or next week. 20:08:26 <nirik> ok... moving on then... 20:08:30 <nirik> #topic #456 Respond to split media naming bugzilla 20:08:30 <nirik> .fesco 456 20:08:34 <zodbot> nirik: #456 (Respond to split media naming bugzilla) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/456 20:08:48 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=628695 20:09:09 * nirik is trying hard to have an opinion on this one. 20:09:53 <mjg59> It seems a reasonable request, but do we know what the documentation impact would be? 20:10:10 <pjones> well, there's a possibility _not_ doing so will cause an anaconda bug when we do split dvds 20:10:54 <nirik> well, thats a ways off isn't it? 20:11:43 <mclasen> is this targeted for f14, or f14+1 ? 20:11:55 <notting> pjones: will this break nfsiso? 20:12:07 * nirik is +0. I'm fine with doing it now, or just waiting until we need to, or whatever./ 20:12:18 <ajax> seems like a reasonable request as long as people suffer the delusion that optical media is viable. 20:12:26 <pjones> notting: yeah, probably 20:12:42 <pjones> well, for the DVD case, anyway 20:13:40 <pjones> I'm thinking if we wanted to enact this (which does seem like a reasonable enough thing to do), some bugs would first need to get filed to track at least anaconda changes to support it. 20:13:50 <pjones> it's not a free change 20:14:09 <mclasen> should we then target it for f15 ? 20:14:12 <mjg59> I think so 20:14:14 <mclasen> no need to rush, it seems 20:14:15 <notting> mclasen: yes, i would think so 20:14:19 * nirik nods. 20:14:33 <pjones> that being said, I think anaconda should be able to do that change generically so that it's a question of when to flip the switch on the compose side 20:14:41 <SMParrish> mclasen: +1 20:14:58 <pjones> I'm +1 to targetting f15 for this 20:15:06 <mjg59> +1 for f15 20:15:13 <notting> +1 for f15 20:15:25 <ajax> +1 f15 20:15:30 <nirik> #agreed This change is desired, but for f15 not f14. 20:15:44 <nirik> #topic #457 Bodhi changes for FESCo input 20:15:45 <nirik> .fesco 457 20:15:46 <zodbot> nirik: #457 (Bodhi changes for FESCo input) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/457 20:16:00 <nirik> https://fedorahosted.org/bodhi/query?status=new&status=assigned&status=reopened&milestone=Need+FESCo+Approval&order=priority 20:16:08 <nirik> #info cwickert also voted on these in ticket. 20:16:14 <nirik> Shall we do them one at a time? 20:16:27 <pjones> sure 20:16:52 <nirik> 181 - Negative karma comments should require bugzilla numbers: 20:17:05 <nirik> I'm -1 on this I think. 20:17:19 <pjones> I'm +/- 0 on this - it seems like a good idea until I think about it too hard. 20:17:26 <nirik> I think it's great to file bugs, but making it a requirement seems too hard. 20:17:28 <pjones> and then I realize it means nobody will file negative karma. 20:17:30 <pjones> and that makes me sad. 20:17:42 <notting> it seems painful to enforce (input format, etc.) 20:17:51 <ajax> yeah, i'm leaning -1 20:17:52 <pjones> So I guess I'm actually -1 on it, all said. 20:17:56 <nirik> yeah. Also, it may result in junk bugs or people piling on to an existing one. 20:18:02 <notting> as much fun as 'Related: rhbz#12345' would be 20:18:08 <lmacken> the latest release will turn bug #'s into links 20:18:09 <ajax> -1 doesn't work, Related: rhbz#998 20:18:22 <nirik> lmacken: cool. 20:18:31 <pjones> We could maybe do something else similar though - provide links to the new bug page on the submit form, and make sure there's a way to say that a bug is associated 20:18:38 <pjones> but not actually require it 20:18:39 <SMParrish> In a perfect world I would be +1 but since as pjones says no one will file negative karma to avoid filing a bug I'd lead towards -1 20:18:44 <mclasen> I think it would be nice to have some test feedback ui that deals with both bodhi and bugzilla uniformly 20:18:58 <pjones> mclasen: indeed 20:19:10 <nirik> so, where are we on votes here? -4 ? 20:19:16 <mclasen> but forcing the tester to use both uis seems unfriendly 20:19:18 <pjones> nirik: yeah, looks about right so far 20:19:19 <lmacken> mclasen: ascii mockup plz 20:19:32 <notting> so, yeah, i'm -1 too 20:19:48 <nirik> #agreed no hard requirement on a bug for -karma 20:19:53 <notting> to the particular requirement. i'm open to better ideas on how to solve it 20:19:54 <mclasen> lmacken: I'll try to scare some designers up 20:20:02 <kylem> i'm +1 on it, but that's because we get more negative karma than the rest of you, probably. :P 20:20:03 <nirik> me too. 20:20:13 <mclasen> it would still be useful to have a bug nr. field 20:20:20 <mclasen> maybe 20:20:32 <pjones> yeah, at the very least we want them to be able to say "I'm -1 because of: [buglist]" 20:20:56 <nirik> see above from lmacken ? would linking them in comments be enough? 20:21:14 <pjones> nirik: I'd rather have a form entry to encourage it 20:21:31 <ajax> i almost want -1 without a bz to be worth -0.5 or something 20:21:47 <ajax> carrot, stick, etc. but then you get into weighting arguments. 20:21:49 <pjones> past experience seems to indicate that if we don't ask for it explicitly, it won't be provided. 20:22:05 <nirik> I've seen a number listing them... 20:22:39 <nirik> anyhow, more on this? or move on? 20:23:07 <nirik> 276 - Negative karma should block being pushed to stable: 20:23:10 <nirik> https://fedorahosted.org/bodhi/ticket/276 20:23:22 <notting> mmm, DoS 20:23:27 <nirik> yeah. 20:23:42 <pjones> the caveat in the ticket is, at bare minimum, required 20:24:07 <nirik> do we have stats on how many -karma updates were pushed anyhow? 20:24:15 <pjones> though it seems like the way it's phrased puts rel-eng in a "tiebreaker" position, which is probably undesirable. 20:24:32 <SMParrish> My concern would be someone who gives negative karma may do it out of ignorance or malice 20:24:44 <pjones> SMParrish: yeah, that's certainly a worry 20:24:45 <lmacken> nirik: nope, but I'll write that metric right now 20:24:49 <notting> i dunno about the latter, but it certainly happens for the former 20:25:07 <nirik> poor understanding of the word 'regression' seems to lead to that... 20:25:27 <pjones> nirik: well, we use that word poorly all around 20:25:37 <nirik> "Still doesn't fix my foobar widget, -1" 20:25:37 <pjones> but let's not get started on that subject ;) 20:25:41 <nirik> right, sorry. 20:26:12 <nirik> so, I am -1 on this unless it turns out to be a common problem... in which case we should look at those packages/maintainers that do it to see why... 20:26:45 * notting is -1 for the DoS issues. although i certainly think we should *track* updates pushed with negative karma 20:27:11 <nirik> yeah, adding some kind of report on that would be good... not sure how hard that would be. 20:27:25 <ajax> yeah, i'd rather see this monitored before it's legislated 20:27:37 <SMParrish> I am -1 as well. But agree with notting we need track the updates. 20:27:52 <pjones> I'm +1 to notting's statement. 20:28:05 <nirik> is there anyone would would be willing to take that an action? or at least see if lmacken might be able to add that to bodhi reporting somehow? 20:28:35 <notting> can we redirect the ticket? 20:28:56 <lmacken> I just wrote the metric for seeing how many stable updates we have pushed with negative karma. Grabbing the latest db snapshot and running it now... 20:29:00 <nirik> #agreed will not have negative karma block updates to stable. 20:29:12 <nirik> #info need to gather info on how much of a problem this is. 20:29:19 <nirik> notting: possibly? 20:29:50 <notting> nirik: will comment in the ticket 20:29:54 <nirik> perhaps the ticket submitter would be willing to help. ;) 20:29:57 <nirik> notting: thanks. 20:30:08 <nirik> 294 - Notes should not be described as optional in New Update Form: 20:30:18 <nirik> https://fedorahosted.org/bodhi/ticket/294 20:30:42 <notting> +1 20:30:51 <SMParrish> +1 20:31:01 <mjg59> +1 20:31:02 <pjones> +1 20:31:09 <nirik> +1 here too. 20:31:22 <ajax> +1 20:31:25 <nirik> #agreed This should be implemented. 20:31:56 <lmacken> I'll take care of it 20:31:59 <nirik> The patch just points to the wiki page, which might be fragile... but ok. 20:32:38 <nirik> 277 - Submitter should not be able to raise karma 20:32:46 <nirik> So, this is a fun one. ;) 20:33:05 <nirik> https://fedorahosted.org/bodhi/ticket/277 20:33:17 * notting is ok with this. although it should be add/remove karma. doesn't make sense for them to be able to lower it if they can't reverse that later 20:33:26 <kylem> i agree with that, +1. 20:33:38 * SMParrish also agrees +1 20:33:53 <kylem> er, i agree with notting's reinterpretation :) 20:33:54 <nirik> I think we should hopefully assume the maintainer has tested the update they have produced... 20:34:01 * mclasen has no problem with this, +1 20:34:04 <ajax> +1 20:34:05 <kylem> nirik, i don't think that's a fair assumption tbh. 20:34:06 <pjones> yeah, +1 20:34:20 <nirik> kylem: why not? 20:34:33 <pjones> nirik: because developers are notoriously poor testers 20:34:36 <nirik> I'm +1 for this ticket with notting proviso about removing as well. 20:34:49 <kylem> nirik, laziness not maliciousness, may not be running, say, F-12. 20:34:54 <nirik> ok, by that reasoning we should allow them to add karma for updates they really do test. 20:35:36 <nirik> I'll note that people have been doing: autokarma +1, and then adding their own +1 20:35:50 <mjg59> Yeah, that's obviously not playing by the rules 20:36:17 <nirik> anyhow, we have enough to approve this... 20:36:38 <nirik> #agreed update submitters should not be allowed to add or remove karma to updates they submitted. 20:36:55 <nirik> ok, moving on. 20:37:14 <nirik> #topic http://fedoraproject.org/wiki/Features/DNSSEC_on_workstations 20:37:14 <nirik> .fesco 434 20:37:15 <zodbot> nirik: #434 (F15Feature - DNSSEC_on_workstations - https://fedoraproject.org/wiki/Features/DNSSEC_on_workstations) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/434 20:37:23 <nirik> on to f15 features. ;) 20:37:27 <kylem> woo :) 20:37:34 <nirik> we had some outstanding questions on this one... do we still have them? 20:38:21 <notting> is there a reason it's a checkbox to enable, rather than a checkbox to disable? 20:38:46 <nirik> good question. 20:39:01 <notting> also, if NM starts requiring dnsmasq for its own resolving purposes, this would seem to be in conflict with that 20:39:10 <mjg59> May have been covered last week, but: has dcbw said anything about this? 20:39:30 <mjg59> If dnssec is expected to work, why is there a checkbox at all? 20:39:47 <nirik> nothing that I know of. 20:40:01 * notting adds questions to the talk page 20:40:04 * mclasen had wondered about the need for a checkbox as well 20:40:07 <nirik> proposed: add questions to talk page, revisit next week? 20:40:14 <mjg59> Assuming updates, yeah 20:40:24 <ajax> nirik: aye 20:40:37 <pjones> yeah 20:40:41 <ajax> though i'm almost certain this will actually break in deployment 20:40:41 <nirik> #agreed ask questions and revisit next week. 20:40:54 <mjg59> ajax: It's DNS and it's crypto, so absolutely 20:41:01 <nirik> can someone ask dcbw? 20:41:20 <mjg59> Well, I'd kind of hope that the feature owners would do that... 20:41:23 <mclasen> I'll ask dcbw to chime in 20:41:24 <mjg59> But yeah, I'll try to 20:41:38 <ajax> like, i bet if i turn this on and then work from coffeeshop it'll refuse to load the redirect page so i can pay for service. 20:42:13 <mjg59> ajax: DNS is usually correct in that case 20:42:20 <mjg59> IP over DNS wouldn't work otherwise 20:42:30 <nirik> ok, shall we move on? 20:42:32 <nirik> #topic http://fedoraproject.org/wiki/Features/GoldLinkerDefault 20:42:33 <nirik> .fesco 423 20:42:36 <zodbot> nirik: #423 (F15Feature: GoldLinkerDefault - http://fedoraproject.org/wiki/Features/GoldLinkerDefault) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/423 20:42:41 <nirik> gold again. ;) 20:42:59 <notting> solid gold? 20:43:07 * nirik looks for the dancers 20:43:09 <pjones> ajax: the normal coffesshop setup we often see is correct dns, but a web server that gives a meta-redirect instead of the thing you're looking for. 20:43:53 <nirik> anyhow, we also had some questions here around the kernel and prelink 20:44:09 <ajax> yeah, i still don't have any answers on that that i know of. 20:44:21 <notting> http://sourceware.org/bugzilla/show_bug.cgi?id=11805 is listed as fixed 20:44:49 <ajax> (the prelink bug) 20:44:52 <nirik> so, also on this one ping and revisit next week... ? 20:44:53 <kylem> i think the kernel will still be a problem because of complicated linker scripts 20:45:07 * nirik would prefer to land this in f15 early to let us deal with any fallout. ;) 20:45:10 <ajax> kylem: yeah, i suspect kernel will still be ld.bfd 20:45:19 <kylem> nod. 20:45:24 <kylem> nirik, yeah, definitely. 20:45:44 <mjg59> Yeah, +1 to landing it early 20:46:11 <ajax> i can follow up on this with the tools team 20:46:13 <nirik> so, anyone willing to try and ask law for info for next week? 20:46:15 <nirik> great. 20:46:15 * mclasen has been using gold for a while now without any problems 20:46:20 <notting> assuming that the prelink bug isn't lying, i'm +1 to the feature 20:46:25 <nirik> #action ajax will ping tools folks about this. 20:47:13 <nirik> #agreed will revist next week 20:47:21 <nirik> #topic http://fedoraproject.org/wiki/Features/SetroubleshootGuiRedesign 20:47:21 <nirik> .fesco 458 20:47:22 <zodbot> nirik: #458 (F15Feature: SetroubleshootGuiRedesign ( http://fedoraproject.org/wiki/Features/SetroubleshootGuiRedesign)) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/458 20:47:47 <pjones> I'm +1 to this 20:47:54 <nirik> +1 here. 20:48:02 <notting> i'm +1 to the idea from reading the studlycaps alone 20:48:27 <SMParrish> +1 20:48:31 <kylem> +1 20:48:43 <mjg59> +1 20:48:52 <ajax> +1 20:49:02 <nirik> #agreed this feature is approved. 20:49:23 <nirik> we had one more FPC item if we want to address that today... or push it off till next week: 20:49:26 <nirik> #topic #460 FPC ratification: No Mandatory FESCo ratification 20:49:26 <nirik> .fesco 460 20:49:27 <zodbot> nirik: #460 (FPC ratification: No Mandatory FESCo ratification) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/460 20:49:50 <nirik> basically FPC is happy with us only reviewing things when any FPC person asks for us to review something... 20:49:55 * notting is +1 to this 20:50:09 <pjones> well, since we were continuing to revue them at FPC's request, okay. 20:50:15 <nirik> I'm +1 to this as well... of course someone in fesco could ask for a review as well I would think. 20:50:18 <pjones> review even 20:50:23 <SMParrish> +1 as well 20:50:34 <pjones> nirik: sure, but that's also true for old fpc guidelines ;) 20:50:37 * pjones is +1 20:50:38 <ajax> +1 20:50:44 <nirik> sure. 20:50:54 <nirik> #agreed the proposal is accepted. 20:51:37 <nirik> #topic Open Floor 20:51:39 <pjones> which I think obviates #459 20:51:52 <nirik> pjones: yeah... 20:51:56 <lmacken> To answer the question from earlier of 'how many updates have gone to stable with negative karma?' F14: 2 F13: 21 F12: 54 EL-5: 27 EL-4: 2 20:52:19 <nirik> anyone have any items for open floor? 20:52:32 <nirik> lmacken: interesting. 20:52:47 <pjones> nirik: just a housekeeping note - can we not try to schedule for discussion items that have been added since the agenda email was sent? 20:52:58 <nirik> pjones: yeah, sorry about that... my bad. 20:53:04 <pjones> I like to actually try and spend time preparing for this meeting, and that's kindof a lost cause if we keep doing this ;) 20:53:08 <ajax> that sounds like it's a pretty constant rate, actually. 20:53:14 <ajax> since f12's twice as old 20:53:16 <pjones> ajax: given age, yeah 20:53:28 <notting> ajax: with the implication that 'no one cares about el-4'? 20:53:30 <nirik> pjones: agreed. 20:53:33 <notting> (or does that not use bodhi) 20:53:46 <nirik> notting: it does now... but didn't when epel was started... 20:53:53 <ajax> i'm willing to ignore epel for these purposes 20:54:01 <ajax> or at least treat it separately 20:54:04 <lmacken> more bodhi metrics: http://fpaste.org/IGf9/ 20:54:16 <kalev> lmacken: is it possible that for some packages negative karma was added _after_ being pushed to stable and it showed up in the report? 20:54:33 <lmacken> kalev: yes, that is possible 20:55:18 <pjones> kalev: in fact I think we had an example of that happening in the discussion several weeks ago 20:56:49 * nirik has also seen that... 20:57:05 <nirik> any further items for open floor? or shall we call it a meeting? 20:57:45 <ajax> nothing from me. 20:58:07 <pjones> I think we're good 20:58:09 <nirik> ok, closing in a minute then. 20:58:16 <nirik> Thanks for coming everyone! 20:58:30 <nirik> #endmeeting
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
