=================================== #fedora-meeting: FESCO (2011-03-02) =================================== Meeting started by nirik at 17:30:02 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-03-02/fesco.2011-03-02-17.30.log.html Meeting summary --------------- * init process (nirik, 17:30:02) * #516 Updates policy adjustments/changes (nirik, 17:34:13) * mmaslano is -1 in ticket (nirik, 17:36:29) * AGREED: this idea is not accepted at this time. (nirik, 17:40:55) * ACTION: SMParrish_mobile will update the https://fedoraproject.org/wiki/Updates_Policy page to suggest only major bugfixes/security for FN-1 releases. (nirik, 17:42:15) * mmaslano is +1 in ticket to this idea. (nirik, 17:46:59) * AGREED: This idea is not accepted at this time. (nirik, 17:49:47) * #517 Updates Metrics (nirik, 17:50:12) * interested parties are wanted to drive this forward. (nirik, 17:52:49) * #544 List of services that may start by default (nirik, 17:53:46) * LINK: https://fedoraproject.org/wiki/User:Kevin/DefaultServices is the current list (nirik, 18:00:14) * ACTION: notting to check our current list against critpath (nirik, 18:02:39) * AGREED: Will gather more info on dbus and critical path, revisit list next week (nirik, 18:11:21) * #563 suggested policy: all daemons must set RELRO and PIE flags (nirik, 18:11:31) * ACTION: kylem to gather more info, will revisit next week. (nirik, 18:21:37) * #564 Proven packager request (nirik, 18:22:28) * AGREED: withdraw this request now, add them as co-maintainer to a bunch of packages, revist in some time period when everyone has seen them maintain and be good. ;) (nirik, 18:30:22) * Fedora Engineering Services tickets/status update (nirik, 18:30:46) * Open Floor (nirik, 18:44:36) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=638477#c132 (nirik, 18:52:33) * ACTION: mjg59 to ping glibc maintainers and try and open a dialog. (nirik, 18:57:05) * LINK: http://lists.fedoraproject.org/pipermail/rel-eng/2011-February/011584.html (gholms, 18:58:24) * ACTION: gholms to update wiki pages to note that if you used a pre-release you should distro-sync with updates-testing disabled at release time to downgrade to the exact release package set. (nirik, 19:09:21) Meeting ended at 19:17:46 UTC. Action Items ------------ * SMParrish_mobile will update the https://fedoraproject.org/wiki/Updates_Policy page to suggest only major bugfixes/security for FN-1 releases. * notting to check our current list against critpath * kylem to gather more info, will revisit next week. * mjg59 to ping glibc maintainers and try and open a dialog. * gholms to update wiki pages to note that if you used a pre-release you should distro-sync with updates-testing disabled at release time to downgrade to the exact release package set. Action Items, by person ----------------------- * gholms * gholms to update wiki pages to note that if you used a pre-release you should distro-sync with updates-testing disabled at release time to downgrade to the exact release package set. * kylem * kylem to gather more info, will revisit next week. * mjg59 * mjg59 to ping glibc maintainers and try and open a dialog. * notting * notting to check our current list against critpath * SMParrish * SMParrish_mobile will update the https://fedoraproject.org/wiki/Updates_Policy page to suggest only major bugfixes/security for FN-1 releases. * SMParrish_mobile * SMParrish_mobile will update the https://fedoraproject.org/wiki/Updates_Policy page to suggest only major bugfixes/security for FN-1 releases. * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * nirik (153) * mjg59 (47) * kylem (35) * ajax (24) * RobbieAB (23) * gholms (21) * notting (21) * mclasen (18) * SMParrish_mobile (11) * zodbot (11) * Southern_Gentlem (5) * fenrus02 (3) * abadger1999 (2) * hannes| (2) * SMParrish (0) * mmaslano (0) * cwickert (0) -- 17:30:02 <nirik> #startmeeting FESCO (2011-03-02) 17:30:02 <zodbot> Meeting started Wed Mar 2 17:30:02 2011 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:30:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:30:02 <nirik> #meetingname fesco 17:30:02 <zodbot> The meeting name has been set to 'fesco' 17:30:02 <nirik> #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano 17:30:02 <nirik> #topic init process 17:30:03 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 mmaslano nirik notting 17:30:08 <mjg59> Afternoon 17:31:51 * nirik waits for more folks to arrive. 17:31:51 * mclasen is here 17:32:03 * notting is here 17:32:32 * SMParrish_mobile here but mobile. Might get disconnected 17:33:25 <kylem> mjg59, i'm aware. ;-P 17:33:32 <mjg59> kylem: Oh, sorry, there you are 17:33:42 <kylem> hehe. 17:33:46 <nirik> ok, I suppose we can dive on in... 17:33:55 <mjg59> Didn't really have you down as the silent type 17:34:13 <nirik> #topic #516 Updates policy adjustments/changes 17:34:13 <nirik> .fesco 516 17:34:14 <zodbot> nirik: #516 (Updates policy adjustments/changes) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/516 17:34:22 <nirik> I added two new ones here this week... first: 17:34:40 <nirik> 1. Change FN-1 to just security and major bugfix. Nothing else allowed. 17:35:06 <nirik> I think the rationale here was that older releases should be more stable and have less change, which I think happens somewhat naturally... 17:35:27 <nirik> we would need to define what 'major' bugfix was. 17:35:31 <mjg59> I'd like it to be this way, but I don't think maintainers agree 17:35:55 * mclasen thinks it does happen to a large degree; with notable (sometimes notorious) exceptions 17:35:59 <mjg59> And I don't think it's worth pushing strongly. 17:36:13 <SMParrish_mobile> I sort of like this idea. Would encourage people to upgrade if they Want the latest 17:36:29 <nirik> #info mmaslano is -1 in ticket 17:37:01 <kylem> my main concern here is that bug fixes might get missed because the package maintainers don't have the expertise required to backport fixes versus whole version updates, and such. 17:37:34 <notting> i'm not sure this needs to be *mandated*. encouraged? 17:37:35 <nirik> well, thats already the case now, right? 17:37:48 <kylem> notting, yeah, i agree. 17:37:52 <kylem> strong suggest. :) 17:38:26 <mclasen> moving the 'features' repo idea will encourage it some more 17:39:12 <mjg59> Yeah 17:39:14 * nirik is -1 to mandating this, but would be fine with updating the updates_policy page to more strongly suggest it. 17:39:20 <hannes|> sry I missed the ticket could someone give me the url to that ticket, please? 17:39:27 <ajax> hannes|: https://fedorahosted.org/fesco/ticket/516 17:39:35 <hannes|> thx 17:39:45 <ajax> -1 to mandating it 17:39:49 * nirik looks to see what it says now. 17:39:58 <kylem> -1, ditto. 17:40:06 <mjg59> -1 at present 17:40:39 * SMParrish_mobile is OK with wording change to encourage the practice 17:40:52 <notting> -1 to mandate 17:40:55 <nirik> #agreed this idea is not accepted at this time. 17:41:09 <nirik> would anyone like to step up to add wording for this on the updates_policy page? 17:41:41 <SMParrish_mobile> I will 17:41:47 <nirik> SMParrish_mobile: thanks! 17:42:15 <nirik> #action SMParrish_mobile will update the https://fedoraproject.org/wiki/Updates_Policy page to suggest only major bugfixes/security for FN-1 releases. 17:42:29 <nirik> #topic #515 Investigate a "features" repo for stable releases 17:42:29 <nirik> .fesco 515 17:42:31 <zodbot> nirik: #515 (Investigate a "features" repo for stable releases) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/515 17:42:37 <nirik> I guess cwickert isn't here... 17:43:01 <nirik> anyone have anything on this? or defer until we have a concrete proposal? 17:43:06 <notting> nirik: did we skip item #2 from the weekly updates? 17:43:30 <nirik> oh, shoot. 17:43:31 <nirik> yeah. 17:43:36 <nirik> #undo 17:43:36 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x2b025b66e790> 17:43:40 <nirik> Second item: 17:43:50 <nirik> 2. require testing only for packages where people have signed up to be testers. 17:44:17 <nirik> The rationale here is that we don't delay updates that aren't going to get any testing anyhow, only updates where someone is signed up to test them. 17:44:27 <nirik> The big issue here is: how do you tell? 17:44:44 <mjg59> I don't think that's a safe assumption 17:44:59 <mjg59> In that even in the absence of explicit testers people may provide useful feedback 17:45:13 <nirik> true. 17:45:19 <SMParrish_mobile> I would prefer to find testers rather than do no testing at all 17:45:25 <nirik> also, many people only provide negative feedback. 17:45:35 * notting agrees with SMParrish_mobile, and is therefore -1 17:46:05 <nirik> ie, run with updates-testing enabled, and only -1 updates that break things rather than +1 all updates that work... so it may appear that some get no karma, but were in fact really tested. 17:46:59 <nirik> #info mmaslano is +1 in ticket to this idea. 17:47:22 * nirik is -1 to this idea for the reasons above. 17:48:07 <mjg59> Yeah, -1 17:49:25 * mclasen gives a -1 too 17:49:25 <nirik> more votes? 17:49:26 <ajax> -1 17:49:31 <kylem> 0. 17:49:47 <nirik> #agreed This idea is not accepted at this time. 17:50:12 <nirik> #topic #517 Updates Metrics 17:50:12 <nirik> .fesco 517 17:50:14 <zodbot> nirik: #517 (Updates Metrics) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/517 17:50:21 <nirik> kylem: have any chance to poke at this any? 17:51:19 <kylem> no, forgot about it -- was poking the relro stuff this week. 17:51:27 <kylem> anyone else want to pick it up? ;-) 17:52:35 <nirik> no worries. 17:52:49 <nirik> #info interested parties are wanted to drive this forward. 17:53:02 * nirik will move on in a minute if nothing else on this topic. 17:53:46 <nirik> #topic #544 List of services that may start by default 17:53:46 <nirik> .fesco 544 17:53:47 <zodbot> nirik: #544 (List of services that may start by default) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/544 17:53:57 <nirik> ok, so there was some discussion on the devel list this last week on this. 17:54:24 <nirik> 57 posts it looks like. ;) 17:54:57 <mjg59> I think the only real disagreement was that some people would prefer all packages to be off and then have them enabled per-spin 17:55:11 <mjg59> Which, to be honest, sounds like a nightmare to me 17:55:16 <nirik> right, which would 'break' installing from the dvd media/netinstalls/etc. 17:55:58 <nirik> I think we should discuss dbus services, and also the idea that we could leverage critical path for this. 17:57:03 <mjg59> So my practical concern is the situation of a package that contains a daemon and tools, and the tools don't do anything until the service is started 17:57:16 <nirik> example? 17:57:27 <mjg59> Well, cups is an obvious one (but critpath) 17:57:29 <mclasen> nm-cli + NetworkManager ? 17:58:20 <mjg59> My personal expectation is that those packages would work without a manual start step being involved 17:59:00 <mclasen> but really, if the tool gives you a clear error message about the service not running, thats good enough in most cases 17:59:31 <mclasen> _silently_ doing nothing is obviously bad 17:59:53 <notting> nirik: so, perhaps go through the list of exceptions we have, and see what wouldn't fall under the critpath category? 17:59:58 <nirik> for cups, lpq will say it cannot connect to the service, system-config-printer will ask if you want to start it or connect to a remote one. 18:00:09 * SMParrish_mobile agrees 18:00:09 <nirik> notting: good idea. 18:00:14 <nirik> https://fedoraproject.org/wiki/User:Kevin/DefaultServices is the current list 18:00:44 <notting> nirik: that's not propagated well to upper level apps, though 18:02:00 <notting> i can do the comparison to critpath for the next meeting 18:02:17 <nirik> ok. 18:02:28 <nirik> thanks notting 18:02:39 <nirik> #action notting to check our current list against critpath 18:02:47 <nirik> Do we want to say anything about dbus? 18:03:57 <mclasen> my understanding is that if you let systemd handle dbus activation, you gain the possibility to disable the service cleanly, so maybe that should be recommended ? 18:04:23 <nirik> well, it's not entirely clear to me how to manage that... 18:04:46 <mclasen> I've asked lennart to restart his blog series with a post about activation 18:04:53 <mclasen> let me poke him again 18:04:56 <nirik> if default is off there its going to result in weird things like NM not coming up or the like... 18:05:30 <nirik> mclasen: ok, sounds good. 18:05:40 <nirik> so, what do we want to do here? gather more info and revisit next week? 18:05:44 <nirik> it would be nice to put this to rest. 18:06:01 <mjg59> Yeah, I think we want more info on dbus 18:06:15 <Southern_Gentlem> ? 18:06:17 <mjg59> Changing the default behaviour there might prove more problematic in terms of tool beaviour 18:06:23 <nirik> 'ls /usr/share/dbus-1/system-services' should show them. 18:06:28 <nirik> Southern_Gentlem: ? 18:07:12 <Southern_Gentlem> at what point is the point that stuff like systemd or gnome3 has to work or they are postponed to the next release 18:07:42 <mjg59> Southern_Gentlem: This is fesco. Perhaps you want release management? 18:08:11 <Southern_Gentlem> mjg59, this commotte approved them as features 18:08:21 <Southern_Gentlem> committee 18:08:31 <mjg59> Southern_Gentlem: Yes, because that's how the feature process works 18:08:38 <nirik> well, there's alpha and beta and final critera... 18:08:44 <mjg59> But we're talking about services starting by default right now 18:09:18 <nirik> Southern_Gentlem: if you have some issues to bring up, can you do that at the end in open floor? 18:10:03 <nirik> so, proposal: gather more info on dbus and critical path, revisit list next week? 18:10:15 <mjg59> +1 18:10:15 <kylem> sounds good to me. 18:10:50 <SMParrish_mobile> +1 18:11:10 <notting> +1 18:11:21 <nirik> #agreed Will gather more info on dbus and critical path, revisit list next week 18:11:31 <nirik> #topic #563 suggested policy: all daemons must set RELRO and PIE flags 18:11:31 <nirik> .fesco 563 18:11:32 <zodbot> nirik: #563 (suggested policy: all daemons must set RELRO and PIE flags) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/563 18:11:37 <nirik> kylem: you looked into this some? 18:11:49 <kylem> so, i sent an email about this, and spent a while digging, and talked to sgrubb this week 18:12:20 <kylem> apparently pre-core/extras merge there was an internal policy about this inside RH. 18:12:32 <kylem> and after the merge, it kind of got forgotten. 18:13:12 <kylem> so what they'd like, is for us to make it a policy again 18:13:32 <mjg59> kylem: In cflags? 18:13:34 <nirik> for everything? or ? 18:13:47 <ajax> anything network-facing or privileged, iirc 18:13:53 <kylem> nod 18:13:55 <kylem> what ajax said 18:14:02 <kylem> setuid stuff, and daemons 18:14:21 <ajax> i can dig up the original policy page, if we need. 18:14:22 <kylem> i was thinking we could use the last discussion to seed the list, sgrubb already identified a few in the ticket 18:14:30 <notting> right, it was done by per-package patching 18:14:36 <kylem> yup. 18:14:41 <notting> was there any indication why we shouldn't do this for everything? 18:14:44 <nirik> so, it would not be good to just enable this globally? 18:14:47 <kylem> notting, startup cost. 18:15:10 <kylem> if you have long running or infrequently running things, it doesn't matter all that much. 18:15:19 <kylem> as near as i can tell, it's in the noise 18:15:22 <mjg59> When you say "network-facing", does that include network clients? 18:15:59 <ajax> mjg59: just servers 18:16:08 * nirik would think it would be much easier to enable these globally if at all possible. Keeping/identifying exceptions and tweaking them is a lot more work and more error prone. 18:16:26 <ajax> and yeah, fair point, firefox should do that too because firefox is a shellcode injection target 18:16:28 <kylem> nod. i sent an email to jakub about the costs side. 18:16:42 <kylem> ajax, or evince, or anything else that takes untrusted input really. 18:16:44 <mjg59> Ok, so maybe we should defer until we have a better idea abou tstartup costs 18:16:59 <mjg59> Because if we can do it globally for relatively little cost I think that's worth it 18:17:06 <ajax> the relro costs are quite small. it's one additional mmap and one additional mprotect per elf object 18:17:25 <ajax> pie involves more relocation processing on the executable itself 18:17:29 <kylem> the costs of PIE are a bit higher iirc, but still pretty low for the gain. 18:17:52 <RobbieAB> Can PIE code link to non-PIE code or vice versa? 18:17:52 <ajax> but the runtime costs for either are approximately zero, iirc 18:18:01 <kylem> RobbieAB, nope. 18:18:12 <ajax> let's just say no, anyway 18:18:27 <kylem> fortunately DSOs are already pic. 18:18:30 <nirik> I'm fine with defering another week for more info. If the costs aren't bad, I really think globally enabling is much better than trying to tweak some arbitrary list. 18:18:31 <RobbieAB> So surely if it's set in anything linking against glibc it needs to be set for all? 18:18:35 <ajax> it's not an entirely meaningful question: executables are PIE, not libraries. 18:18:44 <RobbieAB> Ah, ok. :) 18:18:45 <notting> pie code needs to link against pic code 18:18:50 <ajax> and you don't link against executables (well, you can, but nothing does) 18:18:52 <kylem> mmm pie. 18:19:11 <kylem> nirik, i think globally enabling is an F-16 feature then? 18:19:16 <nirik> kylem: you ok with following up further on this and revisiting next week? 18:19:24 <ajax> non-pic libs is only an issue on x86 anyway, amd64 simply doesn't allow it. 18:19:27 <nirik> sure. 18:19:38 <kylem> and we could just bung along the identified issues with the maintainers of those packages for f15? 18:20:36 <nirik> well, I suppose if we wanted to we could get the f15 versions to tweak/fix... but it's been off for the last 7 releases, does it matter much for one more? 18:20:38 <kylem> sure, sounds good to me. i don't mind it. 18:21:27 <kylem> perhaps i'll talk to steve about poking the maintainers and fesco won't need to be involved for f15 at all. 18:21:37 <mclasen> for f15, it would probably just be individual daemons that can be fixed 18:21:37 <nirik> #action kylem to gather more info, will revisit next week. 18:21:46 <nirik> yeah. 18:22:00 <nirik> ok, anything more on this? or shall we move on? 18:22:28 <nirik> #topic #564 Proven packager request 18:22:28 <nirik> .fesco 564 18:22:29 <zodbot> nirik: #564 (Proven packager request) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/564 18:22:52 <nirik> This request was kicked to fesco... a few sponsors were wanting to see more activity. 18:23:11 <ajax> pkgdb doesn't have meaningful groups 18:23:22 <nirik> yeah, or really groups at all. ;) 18:23:33 <ajax> so every time desktop hires someone new, we have to either go ask for a mass acl change, or just ask for provenpackager 18:23:57 <nirik> right. 18:24:12 <ajax> (disclosure: cosimo sits three cubes away from me) 18:24:13 <nirik> the problem with asking for provenpackager is that the community doesn't know the new person at all... 18:24:21 <RobbieAB> Might the correct fix be adding groups? 18:24:35 <ajax> RobbieAB: well, yes, but that's been the correct fix for four years now, with no progress 18:24:43 <nirik> There may be plans for that, but it's not currently implemented anywhere. 18:24:55 <ajax> certainly the right thing to do with this ticket is say no and just poke toshio or whoever for a mass acl change 18:25:06 <RobbieAB> Ok, so I'm not missing something obvious. :) 18:25:13 <ajax> but we could get groups any day now and that'd be just lovely 18:25:19 <nirik> So, my suggestion: withdraw this request now, add them as co-maintainer to a bunch of packages, revist in some time period when everyone has seen them maintain and be good. ;) 18:25:44 <ajax> wfm 18:26:04 * mclasen will continue to do his mass builds all alone :-( 18:26:23 <SMParrish_mobile> I would prefer the mass acl change to avoid the appearance of favoritism for rh people 18:26:24 <nirik> votes? other ideas? comments? pie? 18:26:51 <kylem> \pi 18:26:56 <notting> pie was the previous agenda item 18:26:57 <ajax> +1 to nirik's suggestion (where the acl list is basically anything mclasen can commit to) 18:27:19 <ajax> er, anything mclasen has explicit acls for; don't remember if he's pp or not 18:27:33 <notting> +1 to that 18:28:31 * nirik sees +3 so far 18:28:50 <abadger1999> If someone wants to do the work to add groups I'd be more than happy to mentor them in doing it -- mass acl changes should be easier to do (can be done by a cvsadmin) once we get the next pkgdb release tested and deployed. 18:29:03 <SMParrish_mobile> +1 18:29:04 <abadger1999> Those are just notes, shouldn't affect the current discussion. 18:29:32 <kylem> abadger1999, thanks for the info. 18:29:36 <kylem> +1. 18:30:22 <nirik> #agreed withdraw this request now, add them as co-maintainer to a bunch of packages, revist in some time period when everyone has seen them maintain and be good. ;) 18:30:26 <nirik> thanks abadger1999 18:30:46 <nirik> #topic Fedora Engineering Services tickets/status update 18:30:55 <nirik> RobbieAB: you still around? whats the news from FES? 18:31:00 <RobbieAB> I am around. 18:31:14 <RobbieAB> things are mostly ticking over. 18:32:06 <RobbieAB> Josemm has the "cross desktop help" ticket, says the consensus with the documentation team is an icon on the desktop as a launch point. 18:32:33 <mjg59> RobbieAB: Gnome's not really sticking with the icons on desktop thing 18:32:44 * mclasen points out that gnome will not have desktop icons soon 18:33:39 <RobbieAB> That may complicate it slightly. :) (ticket is https://fedorahosted.org/fedora-engineering-services/ticket/17 ) 18:33:48 <mclasen> I will comment there 18:33:58 <RobbieAB> Ok. :) 18:34:06 <nirik> cool. 18:34:20 <RobbieAB> The other ticket he is looking at was the "high activity bug script" one. 18:34:53 <nirik> yeah, thats a tough one... 18:35:08 <RobbieAB> We are thinking, if there is a central mailbox getting CCed to all bugs, would a summary of what bugs produced emails be an acceptable solution? 18:35:08 <nirik> I still think it would be great to have if we can come up with a way to gather the info. 18:35:54 <RobbieAB> A little ugly, I know, but as I understand it, it would actually meet the desired "heat measure" objective. 18:36:23 <nirik> not sure there is such a mailbox. ;( 18:36:49 <RobbieAB> Oh, and link is https://fedorahosted.org/fedora-engineering-services/ticket/24 18:36:52 <nirik> you might be able to 'watch' all the fedora project? 18:37:25 <RobbieAB> "We have all our bugs cc'ing extras-qa@xxxxxxxxxxxxxxxxx, I wonder if we could do some kind of processing of those bugzilla emails and do a report weekly on them?" 18:37:40 <nirik> extras-qa -> /dev/null 18:37:59 <nirik> we could change it, but not sure to go where... 18:38:02 <mclasen> so we measure heat in bugmail/s ? 18:38:15 <RobbieAB> That was the suggestion. 18:38:16 <nirik> yeah, not ideal for sure... 18:38:22 <nirik> but all the other ways have failed. 18:38:42 <mclasen> reminds me of the 'beardsecond' 18:38:54 <RobbieAB> And I think any of us can probably knock out a script that works given the mailbox... 18:39:43 <nirik> there was some way buggbot had to get all them... 18:40:29 <nirik> yeah, it's 'watching' everyone. 18:40:45 <nirik> Users watching you: bug(g)bot on IRC (mozila/freenode/gnome) <bugbot@xxxxxxxxxxxxxxxxxxxxx> 18:41:21 <RobbieAB> Well, it was a thought. Is it worth pursuing? 18:41:37 <nirik> sure, I can comment in ticket there and we can see what we can get. 18:42:12 <nirik> any other news? 18:42:41 <RobbieAB> I need to start nagging people on tickets. :) 18:43:08 <RobbieAB> One request from me... Would it be possible to have all FES-trac emails cced to me? 18:43:25 <nirik> sure, we can get that setup... might need to ping mmcgrath. He's the trac admin on it still. 18:43:50 <RobbieAB> I will try pinging hi again than. 18:43:55 <nirik> ok, sounds good. 18:44:03 <nirik> thanks again for getting things moving RobbieAB 18:44:30 <RobbieAB> No problem. 18:44:36 <nirik> #topic Open Floor 18:44:42 <nirik> Anyone have anything for open floor? 18:44:56 <mjg59> I think we probably need to revisit the memcpy situation 18:45:40 <mjg59> Adobe clearly don't care, and no matter how much we tell users they should run the 32-bit plugin they're not going to 18:45:40 <nirik> ok. how can we do that? ;) 18:46:10 <nirik> I was hoping the glibc maintainers would revisit it and at least answer linus'es argument, but they have ignored it. 18:46:23 <mjg59> It also turns out that it's not only Flash that's broken. At least some versions of the Fluendo MP3 plugin are as well, which means it's probably a bug in some reference MP3 implementation. 18:46:24 <nirik> I also think I mailed them asking them to revisit it, and they didn't reply or ack 18:46:41 <mjg59> So I think we need to consider overruling the maintainers in this respect 18:47:07 <mjg59> Or at least threaten to do so 18:47:12 <nirik> ie, just commit a revert? 18:47:31 <mjg59> Yeah, if there's no less invasive means 18:48:33 <nirik> well, does anyone have any other way to contact the glibc maintainers? 18:48:45 <mjg59> Well, I can go via management 18:48:56 <mjg59> But I'm guessing you mean other than that :) 18:48:58 <SMParrish_mobile> The threat of us intervening will get their attention is would hope 18:49:34 * gholms hopes he isn't too late 18:50:04 <nirik> well, I just want them to actually address the technical argument, which they seem to be ignoring... 18:50:15 <mjg59> nirik: I'll mail them 18:50:36 <notting> well, the technical argument is 'it breaks broken things', no? 18:50:59 <nirik> notting: Linus also had good arguments that it increased complexity and didn't in fact make anything faster. 18:51:05 <mjg59> If we broke every piece of code that was broken we'd have very little working code 18:51:32 * nirik digs up the comment in the sea of junk on the bug. 18:51:43 <RobbieAB> What bug? Now I'm curious. 18:52:02 <notting> mjg59: yes, but when it's doing something that the man page has said not to do since C89 or so... 18:52:23 <mjg59> notting: Well, surely that's a somewhat philosophical question? 18:52:33 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=638477#c132 18:52:39 <mjg59> Would we break broken software for no benefit? 18:52:56 <mjg59> And if not, what level of benefit do we need to gain in order to justify the breakage? 18:54:12 <notting> mjg59: at that point you're asking to arbitrarily compare a level of benefit from a performance optimization in memcpy vs a level of benefit in redoing udev/device-mapper integration, for example 18:54:20 <notting> hard to compare apples to kumquats 18:54:24 <mjg59> notting: Right 18:54:50 <nirik> anyhow, if we can reach out to glibc maintainers and get at least some feedback we can revisit next week? 18:54:51 <mjg59> notting: And for Fedora I think it's a completely justifiable question to ask "How much does this performance optimisation benefit Fedora" 18:55:39 <mjg59> I'll mail the maintainers, anyway 18:55:46 <gholms> Is this the Flash/glibc bug again? 18:55:51 <ajax> yes 18:55:54 <gholms> ... 18:56:04 <nirik> I expect if we revert, they could re-revert, or just threaten to stop maintaining it. 18:56:15 <nirik> but I sure hope it doesn't come to that. 18:56:16 <mjg59> I'm sure they could! 18:56:34 <mjg59> And I'm sure the outcome of that would be entertaining 18:56:49 <mjg59> But we're a distribution, not just an upstream distribution tool 18:56:50 <nirik> yeah. ;( 18:57:05 <nirik> #action mjg59 to ping glibc maintainers and try and open a dialog. 18:57:12 <nirik> anything further on this? 18:57:38 <nirik> or other open floor topics? 18:57:42 * gholms raises hand 18:57:56 <nirik> gholms: go ahead... 18:58:21 <gholms> So a couple weeks ago I asked the rel-eng list if they had any thoughts on how having updates-testing on by default in beta causes breakage and got no response whatsoever. :-\ 18:58:24 <gholms> http://lists.fedoraproject.org/pipermail/rel-eng/2011-February/011584.html 18:58:39 <gholms> Have any of you had any additional thoughts on that issue? 19:00:18 <nirik> well, anything from qa folks? 19:00:44 <gholms> I sent that message to that list as well and it never made it out of moderation, from the looks of it. 19:00:49 <nirik> I'm personally leaning toward documenting the issue and noting a distro-sync before release with updates-testing disabled would be the way to go. 19:02:01 <nirik> because we really want people using pre-releases to be helping us test. 19:02:22 <notting> i'd be ok with that. i think the benefit of having it on outweighs the risks 19:02:25 <gholms> I'm personally fine with that. All I really care about is that somebody does something. 19:02:38 <nirik> where would it best be documented? rawhide page? 19:02:41 <nirik> pre-release pages? 19:02:49 <SMParrish_mobile> I'm good with it 19:02:54 <gholms> There's something like "notes for beta users", right? 19:03:55 <gholms> Or perhaps the betas' and alphas' release note pages. 19:04:30 <nirik> nirik: See https://fedoraproject.org/wiki/Upgrading_from_pre-release_to_final and let us know if you have any further questions. 19:04:36 * nirik has a trigger for that one. 19:04:54 <gholms> Perfect! 19:05:09 <nirik> so, should we vote on this? any other opinions? 19:05:09 <mclasen> we may want to make it part of the pre-release process to take stock of pending/testing updates 19:05:18 <mclasen> to avoid these orphans whenever possible 19:05:34 <gholms> Note that that page predates the fedora-release-rawhide package. 19:07:08 <nirik> yeah, needs some work. 19:07:17 <nirik> gholms: would you be willing to update wiki pages? 19:08:05 <gholms> Sure, but I would need to clear up my confusion about how fedora-release and fedora-release-rawhide interact first. 19:08:24 <nirik> ok. we can discuss out of meeting? 19:08:27 <gholms> Sure 19:08:48 <nirik> cool. 19:09:21 <nirik> #action gholms to update wiki pages to note that if you used a pre-release you should distro-sync with updates-testing disabled at release time to downgrade to the exact release package set. 19:09:24 <nirik> anything else for open floor? 19:09:38 <notting> Southern_Gentlem: you had a question? 19:10:25 <Southern_Gentlem> notting just worried that f15 is going be a huge fail if things arent working with gnome3 and systemd 19:11:10 <nirik> sure, always risks. ;( 19:11:22 <nirik> we are just at alpha tho, so I hope we can get things happy by release. 19:11:53 <mjg59> It's not like we force anyone to upgrade to n+1 19:12:14 <gholms> You sort of do when you retire n-1. 19:12:28 <mjg59> Then they can go to n 19:12:32 <gholms> (But that has its own set of issues) 19:12:43 <fenrus02> f15's changelist looks pretty good with those two exceptions really. and systemd has a lot of highly desirable features on the whitepaper. 19:13:38 <gholms> I sincerely hope we will get more systemd packaging documentation before GA. 19:13:55 <notting> gholms: ticket is under discussion. reminds me, need to follow up 19:13:58 <fenrus02> i'm hoping i can actually have a working system by then. i've managed to break systemd every install. 19:14:52 <nirik> so, I would say keep testing, and hopefully we can get everything working. ;) 19:14:57 <nirik> not sure what else we can do right now. 19:15:12 * gholms nods :) 19:15:30 <gholms> Thanks for listening to my rants, people. 19:16:02 <fenrus02> gholms, n-2 gets retired, n-1 isnt retired though, just back-burnered. 19:16:22 * gholms was off by one 19:16:42 <nirik> ok, anything further? or shall we call this a meeting? 19:17:43 <nirik> ok, thanks for coming everyone! 19:17:46 <nirik> #endmeeting
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
