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@fedoraproject.org, 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@landfill.bugzilla.org>
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