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