Sorry, two more from last week we didn't get to: #469 App install related issues https://fedorahosted.org/fesco/ticket/469 #470 Look at buildid repo request from jkratoch https://fedorahosted.org/fesco/ticket/470 These will be covered before new business this week. kevin

=================================== #fedora-meeting: FESCO (2010-09-21) =================================== Meeting started by nirik at 19:30:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-09-21/fesco.2010-09-... Meeting summary --------------- * init process (nirik, 19:30:01) * mclasen said he would be a few minutes late. (nirik, 19:30:29) * kylem said he would not be able to make it today. (nirik, 19:30:40) * pjones is vacationing on a tropical beach (nirik, 19:31:06) * currently present are nirik notting mjg59 ajax SMParrish (nirik, 19:33:40) * Updates policy / Vision implementation status (nirik, 19:33:56) * fesco track has ticket types and templates for 'updates issues' and 'update exception request' (nirik, 20:06:37) * ACTION: nirik to ask for feedback from developers on https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft (nirik, 20:08:21) * LINK: https://fedorahosted.org/fesco/newtplticket (nirik, 20:08:48) * http://fedoraproject.org/wiki/Features/DNSSEC_on_workstations (nirik, 20:10:04) * will defer this for now. Try and get NM maintainer and feature owner together to work things out. (nirik, 20:14:01) * http://fedoraproject.org/wiki/Features/GoldLinkerDefault (nirik, 20:14:19) * will defer to next week (nirik, 20:20:36) * #469 App install related issues (nirik, 20:20:40) * will revisit this next week and try and have all interested parties here to hash out a solution. (nirik, 20:34:15) * #470 Look at buildid repo request from jkratoch (nirik, 20:34:52) * LINK: https://fedorahosted.org/fedora-infrastructure/ticket/2387 (nirik, 20:36:41) * will try using the mash data, see if it meets needs. (nirik, 20:46:07) * #464 Fix nss update issues (nirik, 20:49:02) * LINK: https://fedoraproject.org/wiki/Updating_NSS (nirik, 20:50:22) * documenting update process for nss packages. (nirik, 20:51:20) * going to try and simplify packaging (nirik, 20:51:27) * #467 Make Feature Freeze happen sooner. (nirik, 20:52:19) * will ask for clarification on what is exactly being proposed and revisit. (nirik, 21:07:51) * #468 Evaluate incomplete Fedora 14 Features (nirik, 21:09:13) * LINK: https://fedoraproject.org/wiki/Features/Python_2.7 has 4 packages left to rebuild (nirik, 21:10:06) * LINK: https://fedoraproject.org/wiki/Features/GNUstep is at 90% (nirik, 21:10:52) * LINK: https://fedoraproject.org/wiki/Features/D_Programming is at 99% (nirik, 21:11:07) * 3 features are still not 100% (nirik, 21:17:06) * will work with feature owners to make sure they are 100% asap (nirik, 21:17:39) * Open Floor (nirik, 21:18:09) -- 19:30:01 <nirik> #startmeeting FESCO (2010-09-21) 19:30:01 <zodbot> Meeting started Tue Sep 21 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 <nirik> #topic init process 19:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones 19:30:29 <nirik> #info mclasen said he would be a few minutes late. 19:30:34 <ajax> what up 19:30:40 <nirik> #info kylem said he would not be able to make it today. 19:30:59 <mjg59> Afternoon 19:31:05 <mjg59> nirik: I suspect that pjones is still unavailable 19:31:06 <nirik> #info pjones is vacationing on a tropical beach 19:31:12 <nirik> yeah. 19:31:19 <ajax> apologies in advance for being derelict on anything i've been derelict on, i was out of the country last week 19:32:02 * nirik looks around and sees only 3 of us so far. 19:32:18 * SMParrish here 19:32:18 * notting is here 19:32:35 <nirik> cwickert: you around? 19:33:18 <nirik> thats 5 in any case... so I guess we can get started. 19:33:40 <nirik> #info currently present are nirik notting mjg59 ajax SMParrish 19:33:52 <mjg59> 5 appears to be our lucky number 19:33:53 <nirik> Our favorate topic in the world: 19:33:56 <nirik> #topic Updates policy / Vision implementation status 19:33:56 <nirik> .fesco 351 19:33:56 <nirik> .fesco 382 19:33:56 <nirik> .fesco 454 19:34:00 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351 19:34:04 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382 19:34:08 <zodbot> nirik: #454 (pre-release update acceptance criteria) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/454 19:34:31 <nirik> So, I hacked some more on: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft the other day. 19:34:57 <SMParrish> and I worked on the KDE updates policy draft as well https://fedoraproject.org/wiki/SIGs/KDE/Update_policy 19:35:05 <nirik> SMParrish: cool. 19:35:20 * nirik reads 19:35:28 * rdieter lurks 19:35:56 <ajax> nirik: nice! reading the diff now. 19:36:33 <mjg59> SMParrish: I've been looking at the KDE situation some more. My main concern is the tendancy for new KDE releases to require new Qt 19:36:34 <ajax> looks uncontroversial (and good) 19:36:50 <mjg59> There seem to have been a few cases where Qt updates have broken non-KDE Qt apps 19:37:00 <mjg59> And when I saw "a few", I really do mean a few 19:37:01 <nirik> so, basically this means there would be one expected kde exception per release? 19:37:04 <mjg59> It's not the common case 19:37:18 <SMParrish> mjg59: That is always a possiblity, in fact qt4.7 was just released 19:37:37 <mjg59> SMParrish: Yeah. So if KDE 4.5 goes into 13, qt gets bumped as well, right? 19:37:40 <rdieter> nirik: at most 1, could be 0 19:37:53 <SMParrish> mjg59: yes 19:37:57 <mjg59> So ideally the testing coverage isn't just KDE, it's the entire Qt dependency tree 19:38:30 <notting> i still find it odd on a logical level... 'we don't do feature/major updates, except this one we do each release' 19:38:36 <mjg59> I'm also a bit concerned by cases like the Dolphin tooltips 19:38:39 <nirik> notting: yeah. 19:38:55 <mjg59> (summary: dbus threading bug means that the KDE filemanager in 4.5 can lock up randomly) 19:38:55 <nirik> but it is a case where upstream just is not aligned with our release cycle at all... ;( 19:39:03 <ajax> it makes me want to release kde on its own schedule. 19:39:04 <SMParrish> The big issue is that the KDE SIG feels they should be one defining who their target audience is and what updates to provide to them. 19:39:58 <mjg59> So, my concern with KDE updates in a stable release don't really centre around KDE at all. It's the fact that KDE updates often require updates of other system components. 19:39:58 * thomasj lurks 19:40:14 <mjg59> For 4.5 to be stable, right now we'd need to update dbus 19:40:35 <rdieter> mjg59: the dbus problem is in kde-4.4 *now*, it's not exactly a regression 19:40:54 <mjg59> rdieter: Oh? The conversation seemed to surround it being much more of an issue in 4.5 19:41:16 <rdieter> mjg59: it does seem to affect *some* users more now, but the problem remains the same 19:41:43 <rdieter> mjg59: in particular, users who enable some non-default preferences 19:42:19 <notting> SMParrish: by logical extension, then the games sig defines their own audience, the desktop sig does, the firefox sig/maintainers do, and they each have their own separate update policy, and we have the same chaos now that the board requested we fix 19:42:36 <mjg59> rdieter: Well, my point was that the dbus update would change dbus's threading behaviour (in a good way, but...) and again we risk breaking non-KDE components 19:42:50 <notting> SMParrish: for a more concrete example, the FEL sig used KDE as a base, so what happens when their target's expectations clash? 19:42:51 <nirik> I think this policy may be the best we can do without more repos, so I would be willing to give it a go and see if it's workable. 19:42:55 <mjg59> The same if it ends up needing a newer fontconfig, or any other commonly used bit of code 19:42:56 <rdieter> mjg59: true, I'm not arguing for a dbus update 19:43:11 <skvidal> quick question 19:43:18 <skvidal> if we took kde out of the discussion 19:43:22 <skvidal> and said 'firefox' instead 19:43:25 <SMParrish> notting: that may be, the SIGs were given the autonomy to make those decisions for themselves 19:43:29 <skvidal> let's say firefox releases were not in sync 19:43:46 <skvidal> and with each new release firefox immediately deprecated the previous one and would not update it 19:43:52 <skvidal> what would we be doing? 19:43:58 <Oxf13> skvidal: perhaps firefox isn't the best example, because firefox I think was already an exception somewhat to the update rule 19:44:11 <Oxf13> wait, n/m, I think I'm thinking of another OS 19:44:16 <nirik> skvidal: I would suspect something similar to this proposal. 19:44:18 <gholms> Why does Firefox get a free pass? 19:44:25 <skvidal> gholms: it doesn't 19:44:28 <skvidal> so 19:44:32 <nirik> gholms: it does not. 19:44:41 <gholms> Whew, sorry. 19:44:47 <skvidal> nirik: so we're going to end up walking back the policy for anything that hits a lot of people? 19:44:49 <ajax> we'd probably look at what firefox expects in terms of OS requirements 19:44:50 <nirik> currently it's release cycle aligns ok with fedora's. 19:44:53 <skvidal> nirik: or that impacts a lot of people? 19:45:01 <skvidal> nirik: or that a lot of people complain about? 19:45:07 <ajax> in the firefox case, it doesn't really expect a lot... 19:45:25 <skvidal> ajax: xulrunner isn't involved? 19:45:34 <mjg59> skvidal: If Firefox did that, we'd probably be investing engineering time into supporting Firefox 19:45:42 <mjg59> skvidal: I suspect that other distributions would be as well 19:45:55 <skvidal> mjg59: hmm, okay. 19:45:58 <nirik> skvidal: no, I don't think so. I think in cases where upstream release doesn't match up at all with fedora releases, the maintainer(s) can ask for an exception, we can then decide it on a case by case basis. 19:46:26 <ajax> skvidal: mmm. xr doesn't have a huge amount of users outside other moz projects, but fair, i'd forgotten about that 19:46:49 <mjg59> I am minded to say that exceptions are reasoanble for closed sets of well-bounded code which don't have a significant impact upon the rest of the distribution 19:47:12 <mjg59> And that KDE would meet that *if* it doesn't require an update of any non-KDE libraries or daemons. Which would forbid qt updates. 19:47:30 <rdieter> mjg59: agreed, for the sake of this argument, take qt out of the equation 19:47:40 <notting> SMParrish: but if the board is asking us to set an update policy for Fedora, they are (implicitly, if not explicitly) saying *don't* leave it up to the SIGs 19:47:47 <nirik> mjg59: well, thats one part of it sure... but also if the upstream doesn't support the current release anymore, and their are bugs or security issues that can't be backported, etc. 19:47:50 <SMParrish> The issue with KDE is there is no support for previous releases. If there are bug & security fixes they are rolled into the following months release. The KDE sig does not have the manpower to backport these fixes, so a 4.(x+1) bump is going to happen during a fedora release 19:48:10 <nirik> rdieter: can you do a kde update with no qt update? 19:48:14 <rdieter> nirik: yes 19:48:18 <nirik> do they keep supporting the older qt? 19:48:21 <mjg59> SMParrish: So, what do we do when that results in updates that break non-KDE applications? 19:48:46 * mclasen walks in 19:49:01 <nirik> ok, we are at 15min here folks. Votes to keep going? 19:49:08 <thomasj> mjg59, what non-KDE apps do you have in mind? 19:49:10 <nirik> +1 from me. I would like to see more... 19:49:17 <mjg59> nirik: +1 19:49:30 <SMParrish> notting: yes but I dont think the boards mandate was a brick wall saying no updates just make sure what you do works and has no impact on the user experince. The KDEsig works hard to make sure everything is tested and ready to go before pushing to stable 19:49:33 <ajax> +1 continue 19:49:35 <SMParrish> nirik +1 19:49:48 <mjg59> thomasj: Anything that uses libraries which KDE requires a newer version of 19:49:48 <notting> nirik: i'm +1, although what is the end goal of this conversation? are we intending to approve something today? 19:50:04 <mjg59> thomasj: If we don't have to update any of those then there's much less of an issue 19:50:12 <SMParrish> notting: that is why KDE4.5 has not been pushed yet, we are not satisfied that it is ready 19:50:14 <nirik> notting: good question. I don't know... 19:50:30 <mjg59> notting: From my point of view, I'm interested in determinign what the expected boundaries of the exception process are 19:50:52 <nirik> I don't know that the proposed kde process needs anything from us... that basically just says they will request an exception 0 or 1 times per release, right? 19:51:03 * cwickert is sorry to be late 19:51:20 <SMParrish> nirik: right 19:51:24 <mjg59> nirik: I think it's interesting to work out whether or not we'd be likely to say yes to such a request 19:51:26 <nirik> cwickert / mclasen: we are talking about: https://fedoraproject.org/wiki/SIGs/KDE/Update_policy 19:52:03 <nirik> mjg59: sure. I think you are right that with no qt update in the mix it would be easier to say yes... 19:52:28 <mjg59> I'm leaning towards it being ok to update KDE providing that it doesn't bump more generic code in the process. We'll be providing an alternative and functional desktop that doesn't have significant changes during the release, and I think it's reasonable to indicate to users that they should use Gnome if that's what they want 19:53:08 <mjg59> But I pretty strongly think it's unreasonable to update components used by non-KDE packages 19:53:38 <SMParrish> mjg59: I could go along with that 19:53:39 <nirik> of course unless it's needed to fix a serious bug or security issue... 19:53:56 <nirik> ok, so, where are we here then? 19:54:00 <notting> i like the idea of solving the issue that the SIG doesn't have the resources to backport security fixes if needed 19:54:22 <nirik> notting: how can we do that? 19:54:23 <notting> that may or may not be trivial. but it's work that is being done at some level for other OSes 19:54:35 <mjg59> Yeah. For widely used code, it really should be the case that SIGs are able to maintain releases without upstream support. 19:55:07 <mjg59> Does Suse bump KDE in released versions? 19:55:08 <rdieter> notting: true, our efforts include playing a more active role in upstream developement and release-engineering efforts 19:55:16 <SMParrish> notting: have RH hire a few KDE devs :) 19:55:17 <rdieter> mjg59: no 19:55:32 <mjg59> rdieter: How do they manage KDE security? 19:55:33 <SMParrish> mjg59: but we are not Suse either 19:55:49 <nirik> it would also be good longer term to try and get them to either release on a slightly better cycle, and/or somehow support some fixes for the older releases... 19:55:58 <nirik> but thats all longer term 19:56:00 <thomasj> mjg59, they have apid developers working on KDE 19:56:00 <notting> SMParrish: that's not a very community-scalable process 19:56:05 <thomasj> *paid 19:56:15 <mjg59> thomasj: Well, yeah, but they backport security fixes? 19:56:24 <thomasj> mjg59, the paid ones, yes 19:56:39 <mjg59> thomasj: So there's a maintained branch of old KDE versions? 19:56:49 <thomasj> mjg59, not really. 19:56:54 <rdieter> mjg59: suse manages that a bit painfully, I'd imagine 19:56:57 <Oxf13> doesn't RHT have paid developers working on KDE? 19:57:06 <thomasj> mjg59, it gets security fixes, that's it. if you call that maintained.. 19:57:07 <Oxf13> couldn't the two sets work together? 19:57:16 <mclasen> Oxf13: yes, we do 19:57:35 <ajax> one or two, yeah. 19:57:43 <SMParrish> Oxf13: Yes and they do work with the SIG but they are a small handfull and have other duties as well 19:57:44 <mjg59> rdieter: But if someone's doing the security backports, why is it a problem that the KDE SIG don't have the manpower to do so? 19:57:57 <mjg59> rdieter: Extracting the patches from Suse shouldn't be a problem 19:58:32 * skvidal wonders about relying on suse's paid development.... 19:58:33 <rdieter> mjg59: sure 19:58:51 <mjg59> rdieter: So the security argument doesn't seem compelling 19:58:54 * cwickert wonders just like skvidal 19:59:01 <SMParrish> mjg59: Keep in mind that Fedora KDE is basically a vanilla KDE, not sure what Suse may do to customize theres could be alot of work 19:59:04 <mjg59> At present, anyway 19:59:21 <rdieter> mjg59: imo, it is not, it's mostly about bugfixes that land only in branch+1 19:59:34 <mjg59> SMParrish: Sure. I'm just saying that I'm not going to vote for an exception on the grounds of security if it looks like all the necessary work is being just over -> there 19:59:41 <cwickert> mjg59, their branding is in a separate package, so the base should be vanilla kde too 20:00:12 <nirik> ok, for me I think this boils down to: the kde sig plan is ok, they should work to minimize changes they do intend to land to make it easier for an exception to be granted. Longer term: work to make upstream kde better so we don't have to do exceptions... 20:00:53 <cwickert> nirik, I doubt that the upstream part will be succesfull 20:00:56 <ajax> nirik: seems as reasonable as we're likely to get 20:01:00 <mjg59> Instead I'd like to concentrate on ensuring that there's security support for the version we shipped, and make it easier for users to *optionally* get feature updates of software 20:01:10 <nirik> cwickert: surely not quickly, but over time it could be... 20:01:16 <cwickert> and I really think that KDE users always want the latest and the greatest, cause that's what KDE is like 20:01:22 <mjg59> But I'm not strongly wed to that, and even if that's the future I'd like I don't see a huge problem with KDE udpates 20:01:52 <thomasj> cwickert, +1 20:01:52 <ajax> i do feel a bit surprised that security backports are considered such a huge blocker 20:02:17 <notting> cwickert: if we have a backports repo (which has been proposed), it seems like a great candidate for that 20:02:17 <ajax> but maybe that's because being someone who's actually written security fixes is sort of a rare thing 20:02:29 <cwickert> notting, indeed 20:02:29 <nirik> also as the 4.x series goes along, I would hope that the amount of user visible changes would go down. 20:03:14 <nirik> so, re: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft anyone have any changes they would like to make to that? 20:03:43 <SMParrish> nirik: and that is what we are seeing. Upstream is really working on stability and polish atm 20:03:50 <nirik> I think I would like to call for maintainer feedback on it and see if we can polish it over the next week, then next week vote on it? 20:04:11 <ajax> nirik: looks pretty good to me, thanks for running with it. 20:04:33 <mjg59> nirik: "Avoid ABI/API changes where possible. If unavoidable, should coordinate a side tag to rebuild packages in or a mass build/update. " 20:04:38 <mjg59> nirik: Must coordinate? 20:04:40 <nirik> I know it may result in more flames on the list, but I would really like to get feedback and buyin from folks if possible. 20:04:59 <nirik> mjg59: depending on which section, sure. ;) Feel free to change. 20:05:14 <mjg59> nirik: Ideally autoqa would notice a soname bump and tell you how to do that, I guess 20:05:32 <mjg59> nirik: But otherwise, I think this is really solidifying 20:05:36 <nirik> mjg59: yeah. I added a 'We will add autoqa info when it's ready" at the end. 20:05:54 <SMParrish> nirik: Looks good and seems to address the issues 20:06:02 <wwoods> mjg59: tell you how to do what, a side tag mass-build? 20:06:12 <nirik> Oh, I also added 2 things to the fesco track: 20:06:22 <mjg59> wwoods: Yeah, or at least tell you who to talk to to arrange one 20:06:37 <nirik> #info fesco track has ticket types and templates for 'updates issues' and 'update exception request' 20:07:50 <nirik> ok, so ask for feedback and vote on this next week? 20:07:55 <nirik> anything further on updates from anyone? 20:08:21 <nirik> #action nirik to ask for feedback from developers on https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft 20:08:24 <gholms> "fesco track"? 20:08:33 <ajax> ithm "trac" 20:08:39 <gholms> Ah 20:08:40 <nirik> trac, sorry 20:08:48 <nirik> https://fedorahosted.org/fesco/newtplticket 20:09:41 <nirik> ok then, moving on. 20:10:04 <nirik> #topic http://fedoraproject.org/wiki/Features/DNSSEC_on_workstations 20:10:05 <nirik> .fesco 434 20:10:06 <zodbot> nirik: #434 (F15Feature - DNSSEC_on_workstations - https://fedoraproject.org/wiki/Features/DNSSEC_on_workstations) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/434 20:10:09 <nirik> any news here? 20:10:35 <mclasen> dcbw left his comments on the talk page 20:10:50 <nirik> I see that... yeah. 20:10:55 <mclasen> he's implementing caching in nm 20:11:03 <mclasen> not sure if he's had any contact with the feature authors 20:11:34 <mjg59> I think we're just going to have to ignore this until the feature appears 20:11:44 <ajax> i still expect this to break some kinds of wifi login redirects, but i'm okay with that 20:11:49 <mjg59> It would be nice to have default dnssec support out of the box 20:11:58 <mjg59> And I think that's something we should advertise 20:12:07 <nirik> yeah... 20:12:12 <mjg59> But this really needs to be happening as part of NM development, not Fedora development 20:12:21 <nirik> I wonder why the NM maintainer isn't feature owner here? since it's all in NM right? 20:12:37 <mjg59> nirik: At a guess, because nobody talked to him 20:12:41 <notting> it looks like a reasonable thing to have and tout as a feature, but there are the real roadblocks w.r.t. NM changes. so i'm leery to approve it until those roadblocks are worked out 20:12:52 <ajax> an excellent question! "this would be a cool feature, you should implement it for us" 20:13:02 <SMParrish> mjg59: I agree should be part of NM 20:13:08 <mclasen> if anything, nm will probably just grow the caching support without this feature being involved... 20:13:16 <mjg59> Right. I'm not going to vote for it until there's evidence that it's going to land in the nm tree 20:13:27 <nirik> ok, so defer for now? 20:13:31 <mjg59> I suspect that this is a failure of RH internal process, but... 20:13:44 <ajax> yeah, defer 20:14:01 <nirik> #info will defer this for now. Try and get NM maintainer and feature owner together to work things out. 20:14:05 <SMParrish> I agree defer 20:14:19 <nirik> #topic http://fedoraproject.org/wiki/Features/GoldLinkerDefault 20:14:20 <nirik> .fesco 423 20:14:21 <zodbot> nirik: #423 (F15Feature: GoldLinkerDefault - http://fedoraproject.org/wiki/Features/GoldLinkerDefault) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/423 20:14:23 <nirik> any news on this one? 20:14:51 <nirik> I don't see any. 20:14:54 * mclasen hasn't heard anything 20:14:59 <nirik> I can mail the feature owner directly for next week. 20:15:04 <cwickert> nothing on the talk page 20:15:08 <ajax> that was on me 20:15:18 <ajax> and i dropped it on account of xds 20:15:27 <jankratochvil> prelink has been fixed upstream. 20:15:39 <jankratochvil> That is gold for prelink (not prelink). 20:16:10 <mclasen> are we planning a mass rebuild for f15, anyway ? 20:16:22 <Oxf13> "planning" 20:16:27 <nirik> mclasen: not that I know of yet... 20:16:27 <ajax> i don't know of one planned 20:16:42 <Oxf13> generally I don't plan one, and wind up getting notified last minute that we need one :/ 20:16:51 <Oxf13> so at this time, no we are not planning a mass rebuild. 20:16:54 <ajax> prelink was the only major objection i knew of that simply switching to ld.bfd wouldn't fix. 20:17:20 * mclasen points out the gold feature page talks about 'rebuild everything' 20:17:38 <drago01> so lets plan one ;) 20:17:39 <nirik> what about the kernel? 20:17:48 <nirik> and/or anything else that needs to not use it. 20:17:50 <notting> mclasen: that almost looks to be a QA step 20:17:59 <ajax> nirik: that falls under ld.bfd 20:17:59 <notting> mclasen: i.e., 'rebuild everything to make sure it's not broken' 20:18:02 <notting> could be done on the side 20:18:38 <nirik> ajax: yeah, but how does a package use that? is there some easy way in the spec? 20:19:04 <nirik> anyhow, lets ping the feature owner, get more info and revisit next week? 20:19:25 <ajax> nirik: for most makefiles "make LD=ld.bfd" would be enough, i suspect. 20:19:30 <mjg59> nirik: +1 20:19:40 <nirik> cool. I was thinking it would be more of a pain. 20:20:04 <nirik> any objections to defer? 20:20:12 * nirik will move on in a minute if none. 20:20:36 <nirik> #info will defer to next week 20:20:40 <nirik> #topic #469 App install related issues 20:20:40 <nirik> .fesco 469 20:20:42 <zodbot> nirik: #469 (App install related issues) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/469 20:20:55 <nirik> see https://bugzilla.redhat.com/show_bug.cgi?id=488968 20:20:59 <nirik> and discussion on the devel list. 20:21:52 <nirik> rhughes asked us to discuss this. 20:22:07 <ajax> man, that thread hit my tl;dr meter in a serious way. 20:22:43 <SMParrish> was an intersting read 20:22:46 <mjg59> I propose that we just remove all applications from the distribution 20:22:58 <skvidal> the only important criteria in the discussion, imo, is whethere or not repodata should be in the repodata or in a pkg in an rpm in the distro 20:23:00 <nirik> mjg59: hurray! less files. 20:23:00 <geppetto> ajax: I think all the info. was in the BZ 20:23:08 * gholms quietly removes his packages' .desktop files 20:23:11 <mclasen> the question here is in what form to provide additional app-centric metadata 20:23:19 <drago01> summary "disagrement on implementation - packagereview being blocked because it is 'the wrong way' (tm)" 20:23:40 <ajax> geppetto: 44 comments aren't a lot better than 44 emails. but yeah. 20:23:41 <mjg59> Putting it in repodata is certainly ideologically cleaner, but I'm not convinced that it works better 20:24:00 <geppetto> mjg59: How is it worse? 20:24:06 <SMParrish> mjg59: I agree, repodata will bloat 20:24:11 <nirik> we did in the past ship some things like this as packages, and we decided that was a bad idea and stopped doing that. 20:24:13 <skvidal> SMParrish: will bloat? 20:24:20 <skvidal> SMParrish: it is in a separate file 20:24:24 <skvidal> how is 'bloat' important? 20:24:33 <gholms> Will it matter? You can download it only when necessary. 20:24:41 <skvidal> nirik: specspo, comps - as a point in fact 20:24:42 <drago01> the word 'bloat' is way overused ... but ot 20:24:52 * mclasen does rpm -q specspo 20:25:00 <mclasen> specspo still around, how did we stop ? 20:25:01 <skvidal> mclasen: yah - useful isn't it? 20:25:15 <geppetto> mjg59 SMParrish: As I said in the BZ, it's less data than primary … and is much less likely to grow at the same rate 20:25:22 <mjg59> The main issue with doing it in repodata is that if you want any per-spin policy you still need to have data in the archive 20:25:23 <nirik> 'but we are trying to quit' :) 20:25:26 <notting> mclasen: honestly, specspo is still around because we've been too lazy to block it 20:26:01 <mjg59> On the other hand, requiring periodic manual updates of the package isn't sane 20:26:11 <mjg59> And how does it interact with updates-testing? 20:26:26 <mjg59> Or, indeed, updates? 20:26:43 <Oxf13> or rpmfusion? 20:26:46 <mjg59> Yeah 20:26:54 <Oxf13> can the package data be layered? 20:27:03 <mjg59> I think the base data source has to be repodata 20:27:05 <nirik> Oxf13: I was just wondering that. 20:27:08 <mclasen> mjg59: the expectation is that app data is fairly static 20:27:17 <mjg59> mclasen: Well, yeah, but it's not 20:27:19 * mclasen realizes he forgot to invite hughsie to this discussion 20:27:22 <nirik> rpm 'seed' that has data as of GA, and repodata update? 20:27:25 <mjg59> mclasen: People add new packages to existing distributions 20:27:31 <nirik> mclasen: if you can find him that would be great. 20:27:41 <skvidal> nirik: repodata updates a file put in place via pkg? 20:27:48 <notting> probably a bit late in the day for hughsie 20:27:50 <mjg59> nirik: It's 9:30PM in the UK, so he may well not be around 20:27:50 <skvidal> nirik: so rpm -V will show... 20:27:55 <mclasen> he didn't feel well earlier today, he's probably offline 20:28:06 <geppetto> mclasen: Except you just said firefox and KDE are going to get big updates for every release … so, not so much 20:28:07 <nirik> skvidal: no, tools look for repodata and fall back to seed? 20:28:09 <SMParrish> hughsie is not online -( 20:28:22 <skvidal> nirik: umm.. 20:28:22 <geppetto> mclasen: In fact I can't think of any release of any distro. where it wouldn't have changed a few times 20:28:45 <nirik> ie if you are offline? or I guess just say you can't do it unless you are... not sure it buys us much 20:28:49 <SMParrish> I would personally like to get him here to discuss this before we take any action 20:28:52 <mjg59> mclasen: So if two packages get added to updates-testing and the data gets updated there, and then only one of those packages goes through to stable, what happens? 20:28:59 <skvidal> nirik: and offline caches work in yum now anyway 20:29:11 <mclasen> geppetto: I said what ? 20:29:11 <nirik> yeah, so if they were ever online to get it thats moot. 20:29:49 <geppetto> mclasen: You said that it was mostly static, I think in response to the question about how you sync. it if it's in a package 20:29:50 * nirik thinks repodata seems much more sane, but I'd like to see if we can address hughsie's issues with it. 20:30:10 <geppetto> mclasen: I'm just saying … I very much doubt it's mostly static 20:30:16 <mjg59> I'd like to see a proposal for how to keep it in sync with the updates/multiple repo case before deciding anything 20:30:21 <nirik> some of them seem solveable... like the 4hours per run... if it cached all things that didn't change, it should be much faster than thaty. 20:30:21 <mjg59> And I think we need to speak to hughsie about it 20:30:31 <geppetto> mclasen: Well maybe compared to primary, but not objectively 20:30:38 <Oxf13> I'd hate to see this issue get delayed again, but from the outside I don't think it'd be very nice to make a decision without having hugsie here to present his case 20:30:39 <mclasen> geppetto: sure, new apps will happen, but I don't think it is very common for an app to change its icon or menuitem text mid-release 20:30:40 <mjg59> If doing it in packages can be made to work sanely then I don't object to it 20:30:42 <nirik> so where does the pkgdb data fit in here? 20:31:00 <skvidal> nirik: that's a whole other issue 20:31:11 <skvidal> nirik: the pkgdb folks were working on their db 1.5-2yrs ago now 20:31:13 <skvidal> and implemented it 20:31:31 <nirik> right, it would be nice to use the same data and have ratings, etc feed into the same place. 20:31:32 <skvidal> I don't know the background on when richard started working on this or if he talked to them 20:31:55 <mclasen> skvidal: he started about the same time, and he did talk to them 20:31:56 <skvidal> from the posts from maplloin and mbacvosk - it seems he didn't talk to them 20:32:07 <skvidal> mclasen: weird - mbacovosk said he had never heard of it 20:32:09 <skvidal> in an email 20:32:09 <skvidal> today 20:32:17 <mclasen> yeah,thats wierd indeed 20:32:38 <nirik> so, defer to next week, try and make sure hughsie can make it and we can try and hash out a solution? 20:32:42 <mclasen> I know for a fact that they have talked about this (they are both in my team, after all...) 20:32:49 <skvidal> mbacovosk? 20:33:06 <ajax> yep! 20:33:13 <SMParrish> nirik: +1 20:33:14 <skvidal> hmm, I didn't know who he worked for 20:34:15 <nirik> #info will revisit this next week and try and have all interested parties here to hash out a solution. 20:34:24 <nirik> any objections? will move on in a minute. 20:34:50 <nirik> ok, moving on then... 20:34:52 <nirik> #topic #470 Look at buildid repo request from jkratoch 20:34:52 <nirik> .fesco 470 20:34:54 <zodbot> nirik: #470 (Look at buildid repo request from jkratoch) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/470 20:34:55 <notting> yeah, i mentioned in e-mail response to hughsie that we were discussing this today and offered an invitation to come. wasn't really forecful about requiring him come 20:35:20 <nirik> notting: yeah, he was cc'ed on the fesco ticket as well. Sounds like he's under the weather. ;( 20:35:49 <nirik> so, this is a request for buildid features. 20:36:06 <nirik> basically they want a repo that has all debuginfo packages for all packages ever built/shipped. 20:36:35 <nirik> our build wrangler and infrastructure lead both said this is not possible. 20:36:40 <jankratochvil> Even the binary rpms, not just debuginfo packages. 20:36:41 <nirik> https://fedorahosted.org/fedora-infrastructure/ticket/2387 20:36:52 <ajax> ha ha ha ha ha good one. 20:36:55 <nirik> jankratochvil: what action are you hoping for here? 20:37:28 <jankratochvil> At least an approval if there would be viable way that it should be done. 20:37:43 <nirik> we simply don't currently have the infrastructure to make a massive 'everything ever made' repo. 20:37:56 <notting> well 20:38:00 <jankratochvil> I would say yum as-is may be acceptable and I would prefer numbers why it is not acceptable. 20:38:08 <notting> if we're ever going down the road of debuginfo-fs, this would be part of that 20:38:08 <nirik> I think the solution would be best made with upstream koji development... find some way to store the info you need in the db. 20:38:34 <skvidal> everything ever made.... is gonna be a lot of pkgs.... 20:38:34 <ajax> notting: ennh. not really? 20:38:38 <jankratochvil> Such repository would be useful only to the package maintainers for Bugs triaging; so it does not have to be perfectly performance wise, just bearable. 20:38:54 <notting> ajax: you need a repo of 'everything' 20:38:56 <skvidal> my concern is not performance of yum once it has the repodata 20:38:57 <nirik> 31GB of repodata is bearable? 20:39:03 <skvidal> it's getting the repodata 20:39:07 <skvidal> that makes me want to cry 20:39:22 <ajax> the only reason that "everything ever" would be useful, in a difs kind of world, is if you get a bug report from a user who's not updated in ages and his debuginfo packages have been gc'd away 20:39:22 <skvidal> screw worrying about deltas - the first time is gonna be the bludgeon 20:39:27 <jankratochvil> notting: As I said for the bugs triaging debuginfo rpms are not enought, you should setup a system with equivalent package NVRAs as the reporter had. 20:39:27 <Oxf13> yeah, that's a giant download 20:39:31 <nirik> jankratochvil: so the use case here is: someone has a crash with some packages that are no longer shipped? 20:39:34 <Oxf13> not to mention that the createrepo task would never finish 20:39:49 <skvidal> Oxf13: hey - maybe we should just throw cpus at it :) 20:39:52 <Oxf13> every time it would finish a run (which would take hours) there would be another few hundred packages built and the repodata would be out of date 20:39:54 <ajax> and i think the answer for that scenario, particularly for a rawhide kind of world, is "harden up and update" 20:40:15 <dgilmore> nirik: I spoke with the koji devs we feel it should be a standalone app 20:40:26 <dgilmore> we dont feel it belongs in koji 20:40:36 <jankratochvil> ajax: In fact every bugreport has at least one package updated. Triaging a backtrace to find out after an hour - I would need even this library but I no longer have it - so next time - is a loss of time from my experience. 20:40:53 <nirik> ajax: yeah, which is often what the developer would say... "there have been 10 releases since then, can you see if the new one fixes this"? 20:40:57 <jankratochvil> nirik: Yes, in fact the same line. 20:41:06 * skvidal hmms 20:41:20 <ajax> jankratochvil: that's "bug report is from a days-old system", not "bug report is from a months-old system" 20:41:23 <nirik> dgilmore: so something that watches builds and gathers the info in it's own db? 20:41:32 <dgilmore> nirik: yep 20:41:40 <ajax> koji's gc rate isn't that fast 20:41:58 <jankratochvil> Oxf13: I am proposing creating some repository-per-day. The yesterday builds are done, yesterday repository no longer has to be touched. Clients (bug triaged) can use many repositories for each day of the builds. 20:42:22 <ajax> i think you're solving the wrong problem 20:42:38 <Oxf13> jankratochvil: all the repositories are found on http://kojipkgs.fedoraproject.org/mash/ 20:42:48 <Oxf13> and mash/updates/ 20:43:00 <geppetto> jankratochvil: So you don't want "all packages" … just "all released packages for a specific release"? 20:43:13 <jankratochvil> I did not know /mash/. That may be enough. 20:43:22 <geppetto> jankratochvil: So they'd be a F-12-all, F-13-all, etc. 20:43:34 <jankratochvil> yes 20:43:55 <geppetto> Ok … you probably want to ask for that then, as that's much more doable, IMO 20:44:01 <jankratochvil> that would be in fact enough, people mixing packages across releases exist but let they be unsupported. 20:44:07 <nirik> Oxf13: that occasionally gets GCed doesn't it? 20:44:23 <geppetto> IIRC it's like 50% overhead for updates-all, vs. our current updates-latest 20:44:24 <notting> nirik: there is no automatic GC of that 20:44:29 <Oxf13> nirik: yes, but not so that you'd have less than a month of archive or so 20:44:31 <dgilmore> nirik: manually 20:44:32 <jankratochvil> If it gets GCed, nothing more can be done with it anyway. 20:44:35 <nirik> right, but releng can nuke them manually. 20:45:00 <nirik> so, where do we go on this now? 20:45:05 <jankratochvil> If you says "no such package" or if it says "404 downloading package" is not much a difference. 20:45:28 <jankratochvil> I can try this /mash/ in practice, I would say the request is resolved now, thanks. 20:45:36 <ajax> woo 20:45:47 <nirik> excellent. 20:45:52 <Oxf13> jankratochvil: sorry I didn't think to mention that to you earlier :/ 20:46:02 <dgilmore> nirik: i think the most efficient is a combo build-id db app and a yum plugin to query it and grab debuginfo rpms from koji 20:46:07 <nirik> #info will try using the mash data, see if it meets needs. 20:46:21 <notting> nirik: it's sort of like the old rawhide/branched trees, which we manually GC once a year or so 20:46:26 <nirik> dgilmore: yeah, sounds reasonable... 20:46:39 <nirik> anything more on this? or shall we move on now? 20:46:48 <dgilmore> notting: ive been doing it more frequently lately 20:46:52 <skvidal> dgilmore: tie it into debuginfoinstall - since it has a bunch of other zany code 20:47:01 <jankratochvil> Some build-id only index would be small enough but that requires some yum or yum-caller coding. 20:47:03 <dgilmore> skvidal: :) that works too 20:47:18 <skvidal> jankratochvil: not terribly difficult, I suspect 20:47:52 <jankratochvil> I have to repeat debuginfo rpmsare not enough, you need even the binary rpms, readonly code/data may be needed for data analysis while not present in .debug files. 20:47:52 <nirik> ok, moving along then... thanks for the input on this one everyone... 20:48:49 <nirik> jankratochvil: ok, see how far you get with mash dirs and we can revisit after that. 20:49:02 <nirik> #topic #464 Fix nss update issues 20:49:02 <nirik> .fesco 464 20:49:03 <zodbot> nirik: #464 (Fix nss update issues) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/464 20:49:35 <nirik> emaldona_mtv has been documenting the update process on the nss packages. 20:50:10 <nirik> Toshio was going to look at helping him simplify the packaging. 20:50:13 <emaldona_mtv> documented what /me should have been doing 20:50:22 <nirik> https://fedoraproject.org/wiki/Updating_NSS 20:50:45 <nirik> emaldona_mtv: thanks for working on making these updates better. 20:51:10 <nirik> so, this is just FYI... if any fesco folks have input talk to emaldona_mtv or update the wiki page. 20:51:20 <nirik> #info documenting update process for nss packages. 20:51:27 <nirik> #info going to try and simplify packaging 20:51:44 <nirik> anyone have anything more on this? or shall we move on? 20:52:16 <nirik> ok, moving on... 20:52:19 <nirik> #topic #467 Make Feature Freeze happen sooner. 20:52:20 <nirik> .fesco 467 20:52:21 <zodbot> nirik: #467 (Make Feature Freeze happen sooner.) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/467 20:52:33 <ajax> wow, that's some of the best best-practices doc i've seen us ever do 20:52:42 <ajax> big ups to the authors 20:54:03 <ajax> okay, that ticket makes no sense to me 20:54:45 <nirik> basically they would like to move feature freeze up a lot. 20:54:49 <ajax> "we freeze a week before alpha, and that's too soon, so we should freeze a month before alpha instead" ? 20:54:57 <ajax> so we should move it even sooner? 20:55:01 <ajax> i 20:55:03 <ajax> i don't even 20:55:55 <notting> i believe it's a reaction to us constantly slipping the alpha 20:56:02 <ajax> also i don't dig this at all from a raw development standpoint 20:56:09 <nirik> so, I think it's moving feature submission deadline earlier by 2 weeks. 20:56:10 <ajax> we wanted NFR so we'd have _more_ time 20:56:34 * nirik is also somewhat confused too tho 20:56:41 <Oxf13> well, you got more time by having the rawhide tree open while branched tree gets stable 20:57:03 <ajax> Oxf13: remind me what release was the first one developed on an NFR? 20:57:12 <Oxf13> f12 20:57:21 <Oxf13> I think f13 is the first full release with nfr 20:57:32 <Oxf13> although I may have shifted those wrong 20:57:36 <SMParrish> Oxf13: your right it was F13 20:57:41 <nirik> I think thats correct, yes 20:58:16 <Oxf13> if he's just talking about moving the feature submission deadline, I don't see a problem with that 20:58:29 <Oxf13> I'm not into moving the feature freeze much 20:58:56 <notting> but, a statement like "There's not enough time to make a good decision on whether a feature should be enabled by default (or included at all), and not enough time to fall back reliably if the go-ahead decision is changed. " 20:58:59 <nirik> I don't know that this would help prevent any slips at alpha tho... if thats the goal 20:59:04 <notting> implies that it's not talking about the submission deadline 20:59:27 <SMParrish> Oxf13: sounds more like moving the go/no go date to me 20:59:30 <notting> nirik: well, the problem is constant feature landing *at* feature freeze 21:00:03 <Oxf13> and not having enough time between feature freeze and release candidate? 21:00:04 <mclasen> I think it makes sense to know earlier about features that are coming 21:00:07 <Oxf13> I did carp about that this release 21:00:08 <nirik> perhaps we could ask the requestor here to provide a example using the f14 release? what dates would change? 21:00:15 <Oxf13> I wanted a bit more time between feature freeze and release candidate 21:00:20 <ajax> no matter when you move that deadline, someone's going to land something at the last minute. 21:00:24 <Oxf13> nirik: yeah I think that would help. 21:00:26 <Oxf13> ajax: right 21:00:48 <Oxf13> I think the only recourse is to pad the time after the deadline, and before the next deadline 21:01:03 <mclasen> ajax: if you move it, you can arrange things so that the 'last minute before feature deadline' is not also 'last minute before compose' though 21:01:15 <SMParrish> mclasen: +1 21:01:20 <notting> mclasen: yes. 21:01:21 <nirik> I'll note also that we should expand out the Feature policy some. For example, to indicate when and under what situations we enact the fallback process for them. 21:01:26 <ajax> mclasen: true. 21:01:34 <notting> mclasen: that was a plan at some point. 21:01:35 <Oxf13> mclasen: the trick is to not let people think "oh, I can just slip in the fixes after the deadline but before the REAL deadline 21:02:34 <nirik> so, ask submitter for more info and revisit? 21:02:45 <nirik> or do we have a proposal to vote on here? 21:03:29 <ajax> the schedule the submitter is asking for does have "one week between feature land and compose readiness". no? 21:03:38 <ajax> excuse me, the schedule he's objecting to. 21:03:45 <Oxf13> I would propose (off the cuff) of adding one more week between feature freeze and release candidate 21:04:17 <Oxf13> ajax: yes, I believe the current schedule has one week of time between those events 21:04:57 <nirik> so, that would move feature freeze up one week? 21:05:00 <notting> right, there is feature freeze/branch date, and one week to 'alpha change deadline' 21:05:23 <nirik> except thats not what the ticket is talking about...he's talking about feature submission deadline I thought. 21:06:27 <ajax> it sounds like we're unsure what we're voting on 21:06:35 * nirik is happy to adjust, but it's unclear what he's asking for... 21:06:39 <ajax> so let's ask for clarification 21:06:49 <SMParrish> ajax: +1 21:06:54 <nirik> ok, would someone like to do so in the ticket? 21:07:13 <Oxf13> yeah, that's why I said "off the cuff" when was poorly meant to mean "not necessarily what this ticket is asking for, but my idea for solving the problem the ticket kind of talks about" 21:07:51 <nirik> #info will ask for clarification on what is exactly being proposed and revisit. 21:07:51 <ajax> nirik: yeah, i will. 21:08:17 <nirik> Oxf13: would you like us to vote on that now? or just wait and revist once we know more about what the submittor is asking? 21:08:22 <Oxf13> nirik: nope 21:08:38 <nirik> ajax: thanks 21:09:00 <nirik> ok, if nothing else on this, moving on... 21:09:13 <nirik> #topic #468 Evaluate incomplete Fedora 14 Features 21:09:13 <nirik> .fesco 468 21:09:14 <zodbot> nirik: #468 (Evaluate incomplete Fedora 14 Features) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/468 21:09:18 <nirik> speaking of features. ;) 21:09:30 <mjg59> Most of these seemed to have been updated to 100% 21:09:45 <nirik> yeah, looking to see which aren't. 21:10:06 <nirik> https://fedoraproject.org/wiki/Features/Python_2.7 has 4 packages left to rebuild 21:10:22 <notting> ... and is not going to be reverted for those 4 packages. so, nothing to do here? 21:10:42 <mjg59> I think we're left with Python 2.7, which sounds under control, GNUstep, which, well, and D - I'm not clear on what's left to do for D? 21:10:52 <nirik> https://fedoraproject.org/wiki/Features/GNUstep is at 90% 21:11:07 <nirik> https://fedoraproject.org/wiki/Features/D_Programming is at 99% 21:11:33 <ajax> gnustep? what year is it? 21:11:56 <nirik> I'd guess the D thing is waiting for the final approval of the packaging guidelines? 21:12:06 <nirik> GNUStep hasn't been updated in a while. 21:12:37 <notting> yes, but if the only open issue is the examples package hasn't been reviewed yet... 21:13:19 <nirik> yeah, that seems like all I can see. 21:13:44 <nirik> it's been approved. 21:13:50 <nirik> but not imported and built yet 21:13:59 <nirik> today in fact. 21:14:42 <nirik> so, I think we can say all these are ok... barring information we don't have. 21:14:55 <gholms> It hasn't been built and you're approving it? 21:15:29 <nirik> gholms: it's just an extra examples package. I don't think it's a big deal either way if it was in or not... 21:15:43 <gholms> Just the one package. Got it. 21:16:00 <nirik> and it's approved and ready to build, so I don't see why it wouldn't be built later today and go to 100% on the feature. 21:16:35 <nirik> anyone have anything else on these features? 21:16:47 <ajax> not i 21:17:06 <nirik> #info 3 features are still not 100% 21:17:39 <nirik> #info will work with feature owners to make sure they are 100% asap 21:18:09 <nirik> #topic Open Floor 21:18:17 <nirik> anyone have anything for open floor? 21:18:31 <nirik> Oh, I had one thing: 21:18:48 <ajax> i have one, but you first. 21:19:00 <nirik> Tomorrow is the f14 beta readyness meeting. I won't be able to attend due to another meeting. Would someone be able to attend for fesco ? 21:19:52 <mclasen> what time is it ? 21:20:18 <nirik> Wednesday, September 22, 2010 @ 21:00 UTC (17:00 EDT/14:00 PDT) 21:21:02 <ajax> i can't make that, i have a concall then 21:21:28 <SMParrish> I can be there atleast until 545 or so 21:21:39 <nirik> SMParrish: that would be great if you could. 21:22:21 <nirik> ajax: you had something? 21:22:33 * mclasen not going to make it at that time 21:22:48 <ajax> yeah, talked to #tools on Some Other IRC Network 21:23:00 <notting> (sorry, had a drive-by) 21:23:13 <ajax> basically there's no strong push to switch to gold from their perspective and they don't have anyone spending cycles on it atm 21:23:32 <ajax> law@ is on paternity leave, which would explain why he's been pretty quiet about it 21:23:54 <notting> would they like to defer it? 21:24:11 <ajax> i suspect we'll get a hack pretty soon to make it easier for individual packages to opt-in to gold if they want, but as a default switch it's not going to be an F15 feature 21:24:25 <nirik> ajax: ah ha. Ok. 21:24:46 <mclasen> ajax: isn't opt-in just as easy as opt-out ? make LD=ld.gold ? 21:26:07 <ajax> mclasen: heh, true enough. i think this was more of a CFLAGS hack, since you don't know that the makefile will actually call $(LD) to link 21:26:22 <ajax> (and generally shouldn't, since raw ld invocations tend to get buildid wrong) 21:26:45 <mclasen> does libtool pay attention to LD ? 21:27:14 <ajax> shrug 21:27:23 <ajax> i don't trust libtool further than i can throw its authors 21:28:01 <ajax> that's all from me though 21:28:50 <nirik> ok, anyone have anything else? or shall we call it a meeting? 21:29:00 <SMParrish> I have 1 quickie 21:29:28 <SMParrish> In regards to the recent kernel security issue why did it take a week to get this pushed out? 21:29:33 <SMParrish> anyone know 21:29:50 <notting> for which release? 21:30:17 <SMParrish> f13 I believe came up in an earlier meeting 21:30:40 <nirik> looks like it was pushed on a friday... and we dont do updates pushes on weekends, so it took a while for karma and pushing 21:30:58 <nirik> I assume you mean this one: https://admin.fedoraproject.org/updates/search/CVE-2010-3081 ? 21:31:41 <SMParrish> yes thats the one 21:31:58 <cebbert> it was submitted to testing tuesday night and it took 2.5 days for it to get pushed to testing 21:32:42 <Oxf13> I may not have communicated well with dgilmore that he needed to push f12/f13 updates when I left for Zurich 21:32:57 <Oxf13> so a couple days went by without a push 21:33:06 <SMParrish> Ok seems like in the earlier mtg they were concerned that it was announce on the 13th and did not get tp the repos until yesterday 21:33:38 * dgilmore has been doing them daily 21:33:53 * nirik is happy to push updates on weekends once trained up in sigul speak. 21:33:54 <dgilmore> the longest period without was around 36 hours when i got sick 21:34:39 <cebbert> Date Submitted: 2010-09-15 05:29:33 21:34:49 <notting> cebbert: there was an updates-testing push for f14 late wednesday night. i do not know why the kernel was not included. 21:34:54 <cebbert> Date Released: 2010-09-17 18:03:36 21:35:05 <notting> unless it was submitted in bodhi w/o a push request 21:35:09 <SMParrish> dgilmore: thats understandable and I forgot about the weekend and FUDCon ZRH 21:35:37 <nirik> I'll also note f13/f14 firefox updates are pending... people should test and provide karma. ;) 21:36:31 <hicham> they are not pushed yet to testing 21:36:48 <nirik> hicham: right. You can still download and provide karma tho. ;) 21:36:51 <dgilmore> hicham: you can pull from koji and test :) 21:37:02 * dgilmore is doing a push now 21:37:19 * nirik will close the overtime meeting in a minute if nothing else comes up 21:37:25 <dgilmore> there is no firefox update in the push 21:38:26 <nirik> it might have happened after you started. 21:38:38 <nirik> Thanks for coming everyone! 21:38:43 <nirik> #endmeeting