18:30:00 <nirik> #startmeeting FESCO (2010-11-17)
18:30:00 <zodbot> Meeting started Wed Nov 17 18:30:00 2010 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:30:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:30:01 <nirik> #meetingname fesco
18:30:01 <zodbot> The meeting name has been set to 'fesco'
18:30:01 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59
18:30:01 <nirik> #topic init process
18:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones
18:30:21 <nirik> who all is around for fesco meeting time?
18:30:24 <cwickert> ouch
18:30:29 <mjg59> Hi
18:30:30 <cwickert> that late already?
18:30:31 <pjones> I'm right here.
18:30:38 <kylem> yo
18:30:49 <rwmjones> I'm here ..
18:31:11 <kylem> just like to remind everyone we're doing a townhall with the fesco election candidates tomorrow at 1500 UTC/10AM EST.
18:31:11 <ajax> Uh, I think so Brain, but this time, you wear the tutu.
18:31:33 <nirik> kylem: thanks for organizing that.
18:31:36 <kylem> np.
18:31:54 <nirik> #info townhall with the fesco election candidates tomorrow at 1500 UTC/10AM EST.
18:32:55 <nirik> ok, I guess lets go ahead and dive in.
18:33:09 <nirik> #topic Updates policy / Vision implementation status
18:33:09 <nirik> .fesco 351
18:33:10 <nirik> .fesco 382
18:33:11 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351
18:33:14 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382
18:33:18 <nirik> Our fav tickets. ;)
18:33:33 <nirik> SMParrish: any news on metics?
18:34:01 <nirik> cwickert: were you working on a features repo proposal?
18:34:17 <cwickert> nirik, nope, no time
18:34:25 <nirik> More discussion on list about older stable releases not finding testers...
18:34:32 <cwickert> nirik, have we cleaned up the wiki?
18:35:07 <nirik> not sure. was I supposed to do that?
18:35:11 * nirik looks back at action items.
18:36:14 <nirik> not sure if we had anyone who would do that.
18:36:27 <nirik> Anyone want to step up to do so? If not, I guess I could try...
18:37:14 <nirik> #action nirik to try and remove redundant wiki pages and mark things that are old.
18:37:15 <ajax> what needed doing again?
18:37:30 <nirik> we have the same info in a few places, as well as a bunch of proposals that were never accepted.
18:37:42 <nirik> just need to make sure people don't read those and think thats what we are doing.
18:37:55 * jonmasters here
18:38:17 <ajax> i can take a pass or two at that this week
18:38:28 <ajax> but you're welcome to help
18:38:29 <nirik> ajax: that would be great.
18:38:43 <nirik> #action ajax and nirik to try and remove redundant wiki pages and mark things that are old.
18:39:14 <nirik> so, do we wish to adjust the policy any at this time?
18:39:31 <nirik> There have also been some security updates that are waiting on testing in old releases...
18:39:54 <ajax> as i said last week, i'm fine with turning down the security updates timeout
18:40:04 <mjg59> I'm not enthusiastic about reducing the testing for security updates
18:40:21 <mjg59> But if we don't have the resources to test them more, it may be the lesser of the two evils
18:40:36 <pjones> mjg59: I'm similarly skeptical
18:40:43 <mjg59> We do, ideally, need a team that can verify these packages
18:40:48 <pjones> but yeah, if we're really resource constrained on that, there's not a lot of option
18:40:51 <nirik> yeah, also given how security updates in the past have broken things. ;(
18:41:06 <cwickert> we already removed the "only serious bugs and security issues" limitation, right?
18:41:25 <ajax> and i can see some argument for trying to refine the critpath set further
18:41:26 <nirik> cwickert: which?
18:41:51 <ajax> but in general i really think this is getting what we asked for and what we want
18:42:02 <ajax> if it's important and it can't find testing it must not be that important.
18:42:22 <nirik> it would be nice if we had a way to get some more of the stable release consumers involved in testing... but not sure how. ;(
18:42:46 <notting> sorry, i'll try and be around
18:42:52 <cwickert> nirik, IIRC we had a sentence in the updates policy that must only "fix serious bugs and security issues" and I cannot find it any longer
18:43:05 <cwickert> s/and/or
18:43:58 <rdieter> cwickert: this?  http://fedoraproject.org/wiki/Stable_release_updates_vision "Stable releases should provide a consistent user experience throughout the lifecycle, and only fix bugs and security issues."
18:44:21 <nirik> yeah, the Board vision.
18:44:49 <cwickert> rdieter, thanks, that was it
18:45:20 <cwickert> but it is not in the updates policy, so strictly speaking we did not implement the board's vision?!
18:45:21 <pjones> oh, that old thing?
18:45:25 <nirik> yeah, we have: "Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience"
18:46:16 <nirik> which perhaps is not matching the board vision.
18:47:27 <cwickert> it's not as strict, but IIRC people her did not like it. should we get back to the board and ask them if they are fine with our wording or they should reconsider their vision?
18:47:28 <notting> as I understand it, that was a compromise point.
18:47:45 <cwickert> for me the compromise is ok, the vision is not
18:47:55 * nirik is fine with either. We could ask the Board if they feel our policy is ok.
18:48:23 <nirik> shall I do that?
18:48:27 <ajax> sure.
18:48:37 <ajax> i mean, i would hope they tacitly approve already
18:48:43 <ajax> otherwise they've not been paying attention
18:48:55 <notting> hard to ever assume people are paying attention
18:49:15 <nirik> #action nirik to check with the Board about the updates policy.
18:49:40 <nirik> ok, so does anyone want to propose adjustments at this time to the policy? Or shall we move on?
18:50:30 <ajax> policy, no.
18:50:38 <ajax> critpath set, maybe.
18:51:15 <nirik> well, there were a few people who said they had trouble getting proventesters, but this last week the issues noted were all with non critpath getting any testers.
18:51:40 <nirik> f12 doesn't have too much time left, but still...
18:51:46 <nirik> @f12eol
18:51:50 <cwickert> ajax, what's wrong with the critpath set?
18:52:37 <ajax> cwickert: having not looked at it in detail i couldn't say
18:52:48 <ajax> i suspect it contains too many things
18:52:53 <ajax> i did say "maybe"
18:53:18 <cwickert> there are indeed some odd things due to yum's way to resolve dependencies
18:53:27 <nirik> FYI, there are 5 critpath packages that have been in testing more than 2 weeks without being approved.
18:53:36 <skvidal> cwickert: ?
18:53:42 <pjones> some of which should probably be reworked to not have the deps they do; and when they do, we should re-evaluate critpath.
18:53:45 <notting> ajax: is that a potential future discussion point, or something you'd like to handle today?
18:53:50 <pjones> skvidal: I think he meant "some things are pulled in by deps."
18:53:55 <cwickert> skvidal, xfce4-notifyd was pulled in due to the short name
18:54:09 <pjones> or that.
18:54:18 <ajax> notting: not something i feel we should spend everyone's time looking at right now, no.
18:54:24 <skvidal> cwickert: shortest name is the last of long list of thigns compare_providers does
18:54:27 <nirik> mash, openchrome driver, libwnck, openldap, gnome-settings-daemon.
18:54:41 <cwickert> that is already fixed, but still the 'short name' rule is strange
18:55:20 <notting> nirik: mash is speshul
18:55:30 <nirik> anyhow, if there's nothing we have to consider/propose/vote on here, should we look at moving on?
18:55:30 <ajax> i'll happily take a look at the elaborated list and see if i can't find suss out weird things
18:55:42 <nirik> notting: yeah, I thought about testing it here, but thats only +1. ;)
18:57:19 <nirik> ok, speaking of updates:
18:57:23 <nirik> #topic #493 Hatari update exception request
18:57:26 <nirik> .fesco 493
18:57:27 <zodbot> nirik: #493 (Hatari update exception request) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/493
18:57:39 <cwickert> brb
18:57:46 <nirik> our first exception request.
18:57:57 <nirik> New maintainer took over a old package, wants to update to the newest.
18:57:59 <notting> how nice, they asked!
18:58:06 <nirik> yeah, very nice.
18:58:56 <nirik> sounds like there is a 'old interface' thats the same as the current version and a 'new interface' thats spiffier.
18:59:05 <ajax> an atari emulator!  mission critical.
18:59:07 <nirik> as well as a bunch of bugfixes/backend changes.
18:59:14 * nirik goes to add it to critpath. ;)
18:59:21 <pjones> seems like a pretty clear "what?  no."
18:59:27 <notting> hm. 1.4 dates back to july. le sigh.
18:59:38 <pjones> that's unfortunate.
19:00:35 <kylem> i'm +1 on this since they were nice enough to as.
19:00:37 <kylem> ask
19:01:05 <nirik> since the 'new interface' is seperate, it's unclear to me how much change to the user experence there is...
19:01:14 <notting> it does sound like the new feature is seperable, and does not affect the existing interface
19:01:17 <ajax> yeah, i think i'm okay with this.
19:02:03 <mjg59> On the assumption that nobody's going to be terribly unhappy about their Atari emulator suddenly not working with a given game, sure
19:02:15 <mjg59> But I do think that we need to provide a better mechanism for this
19:02:20 * nirik is also +1 in this case.
19:02:27 <nirik> mjg59: suggestions?
19:02:43 <mjg59> In the long run, separate update repositories
19:03:06 <notting> oh, they pushed the new version for re-review in july, but it wasn't picked up until last week.
19:03:09 <kylem> mjg59, indeed.
19:03:19 <mjg59> app update repositories, that is
19:03:20 <kylem> was this an issue of the MIA maintainer process being slow or?
19:03:25 <kylem> notting, ah!
19:03:41 <notting> realistically, i don't know that they needed a re-review
19:03:45 <nirik> mjg59: yeah, we talked about that. A backports or whatever. We need to come up with a concrete proposal for what it would take to set that up and if we want to do it.
19:04:03 <kylem> hrm. in light of repos.fedorapeople.org, maybe i'm not for or against this...
19:05:17 <nirik> repos.fp.o is handy, but I worry it will become a contrib/
19:05:26 <mjg59> Yeah
19:06:02 <mjg59> I think the ideal solution is an updates repo that just contains security and other serious updates, and a second one that contains *application* (ie, not library or infrastructure) updates
19:06:03 <nirik> it would be nice to have something more integrated that was _just_ newer versions of existing packages already available.
19:06:18 <notting> mjg59: but that's a new thing, obvs
19:06:22 <kylem> oh great, combinatorics explosion of bugs. :)
19:06:23 <mjg59> notting: Right
19:06:37 <nirik> yeah, adds more branches, bugs, mixes, etc.
19:06:50 <mjg59> kylem: Eh. The idea of keeping it at the application level would be that bugs should be fairly independent
19:06:52 <kylem> i like repos because it's explicitly 'no bugs'.
19:07:03 <mjg59> It'd build against updates rather than itself
19:07:05 <kylem> mjg59, except for mismatched python vers, yadda adda.
19:07:12 <mjg59> kylem: Right, no python
19:07:24 <notting> repos.fp.o is versioned
19:07:26 <nirik> so, where are we on this request?
19:07:51 <ajax> i'm +1 since the ui for optional repos is still bad
19:07:52 <nirik> I think we are at +4?
19:08:03 <kylem> kyle: +1, nirik: +1, ajax: +1?, mjg59: +1?
19:08:06 <mjg59> Yeah, +1 in the absence of a better solution at present
19:08:14 <mjg59> And the low risk, etc
19:08:15 <nirik> notting: ? cwickert ?
19:08:20 <notting> same here. +1
19:08:23 <pjones> I'm fairly +0 here.
19:08:39 <nirik> #agreed This package is granted an exception. Thanks for asking.
19:09:04 <nirik> ok, on to features, we have a pile. ;)
19:09:08 <pjones> indeed.
19:09:10 <nirik> #topic #494 F15Feature: BoxGrinder - http://fedoraproject.org/wiki/Features/BoxGrinder
19:09:10 <nirik> .fesco 494
19:09:11 <zodbot> nirik: #494 (F15Feature: BoxGrinder - http://fedoraproject.org/wiki/Features/BoxGrinder) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/494
19:09:11 <kylem> +\Inf
19:09:14 <mjg59> +1
19:09:27 * gholms attempts to summon mgoldmann
19:09:30 <mjg59> Although someone's misinterpreted "Release notes"
19:09:40 <notting> is rel-eng expected to use this?
19:09:40 <mjg59> I'll note that on the talk page
19:10:09 <mgoldmann> notting: that's the plan in long term
19:10:22 <mgoldmann> I'm BoxGrinder lead, hello everyone!
19:10:33 <nirik> +1, looks cool. Perhaps we can mark the reviews somehow to note they block a feature to get them reviewed in time.
19:10:51 <kylem> that looks pretty cool, +1.
19:11:15 * pjones is +1 on this
19:11:18 <cwickert> re
19:11:22 <kylem> nirik, add it to F15Alpha or something?
19:11:36 <nirik> or a whiteboard for it or something.
19:11:44 <ajax> yeah, looks very cool, +1
19:12:12 <kylem> i agree, we should really try to avoid blocking feature process stuff on reviews... we seem to be a little short on reviewer manpower :/
19:12:15 <cwickert> +1
19:12:23 <tibbs> "a little"
19:12:34 <notting> i'm +1, just noting there's a lot of movement in all this cloud space
19:12:43 <kylem> tibbs, understatement of the century, i'm sure. :)
19:12:44 <nirik> yeah, which is a good thing, IMHO.
19:13:00 <nirik> #agreed Feature is approved.
19:13:13 <nirik> #topic #495 F15Feature: CloudFS - http://fedoraproject.org/wiki/Features/CloudFS
19:13:13 <nirik> .fesco 495
19:13:14 <zodbot> nirik: #495 (F15Feature: CloudFS - http://fedoraproject.org/wiki/Features/CloudFS) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/495
19:13:31 <mjg59> +1
19:13:57 <kylem> ah, i wondered how i ended up with glusterfs installed. :)
19:14:03 <pjones> looks reasonable enough to me.
19:14:03 <pjones> +1
19:14:04 <cwickert> +1 because of the 'cloud' buzzword ;)
19:14:30 <kylem> is jdarcy here by some other nick?
19:14:31 <nirik> +1 here.
19:14:33 * notting is +1
19:14:41 <ajax> +1 cloud cloud cloud cloud
19:14:56 <kylem> hopefully this doesn't need any of the userspace crypto blah that we had issues with last go 'round.
19:14:59 <kylem> +1.
19:15:18 <notting> kylem: what do you mean?
19:15:19 <nirik> #agreed Feature is approved.
19:15:27 <nirik> yeah, it doesn't note any kernel deps.
19:15:40 <notting> all the encryption is done client-side, which means userspace (i presume)
19:16:06 <kylem> notting, right, we turned down a feature for kernel-based userspace crypto last cycle, because it was unmerged.
19:16:07 <nirik> yeah, sounds like.
19:16:12 <kylem> (to let the kernel do key management and stuff.)
19:16:25 <kylem> hopefully this doesn't use that for it. anyway. moving on.
19:16:29 <nirik> #topic #496 F15Feature: ConsistentNetworkDeviceNaming - http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming
19:16:29 <nirik> .fesco 496
19:16:29 <notting> kylem: i thought we turned down /dev/crypto b/c it wasn't upstream
19:16:32 <zodbot> nirik: #496 (F15Feature: ConsistentNetworkDeviceNaming - http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/496
19:16:43 <kylem> oh, the fun ticket.
19:16:46 <kylem> notting, we did.
19:16:58 <nirik> I'm +1 on this. I don't care about the naming... no matter what name is picked someone will hate it.
19:17:13 <nirik> and they can always rename them to whatever they like.
19:17:35 <notting> +1. use the 'bob' (Bandwidth On Board) namespace.
19:17:37 <kylem> nirik, i agree, i don't think its job.
19:17:38 <rwmjones> it might be good to add some guidance to how to rename them?
19:17:40 <pjones> I'm +1 on this, despite it being a kindof mediocre solution - we've been trying to find a solution for this for years, and all the others are worse.
19:17:46 <jonmasters> Matt is changing the name again in rawhide today, and he and I have been discussing (e.g. on the phone last night) about namespaces. Not that that matters to getting the feature in.
19:17:56 <mjg59> +1
19:18:03 <kylem> +1.
19:18:04 <cwickert> +1
19:18:12 <ajax> +1 make the bad man stop
19:18:13 <pjones> jonmasters: way to do it in the open.
19:18:18 <gholms> Quick question for you folks about this?
19:18:18 <mjg59> (Despite it not being of any interest to desktop users, who are the only ones we care about)
19:18:20 * nirik notes he has a firewall where he renamed all the interfaces... 'dsl' 'cable' 'wireless'. It's not that hard if you want to.
19:18:44 <jonmasters> pjones: just avoiding bikeshedding. Any proposal will hit the list.
19:19:06 <nirik> gholms: go ahead?
19:19:24 <gholms> If we're going to start using different names for different types of NICs then why not just start naming *everything* according to its type or driver like the BSDs do?
19:19:40 <mjg59> driver is pretty arbitrary
19:19:42 <pjones> gholms: you're thinking of "type" in the wrong way
19:19:43 <mjg59> Type I could live with
19:19:53 <pjones> in bsd land, they mean "by driver".  here we mean "builtin or not"
19:19:56 <mjg59> But yes, it depends on what you mean by "type"
19:20:30 <notting> hm. proposal doesn't list anything about getting seabios to include the necessary info
19:20:36 <pjones> and if you're confused about this, I'd recommend you go find a video of any of the many presentations mdomsch has done on this at various conferences.
19:20:49 <gholms> Ooh, I shall.
19:21:04 <nirik> #agreed Feature is approved.
19:21:05 <pjones> notting: I'd think that'd be an orthogonal issue
19:21:12 <notting> pjones: there are etherpad notes from lpc. http://etherpad.osuosl.org/lpc2010-user-visible-network-issues
19:21:15 <nirik> notting: might note for them to do that.
19:21:22 <pjones> gholms: those might be worthwhile as well ;)
19:21:59 <nirik> anything more on this? or shall we move on?
19:22:32 <kylem> unless we want to argue for hours about names, let's just move on. :)
19:22:35 <nirik> #topic #497 F15Feature: Gnome3 - http://fedoraproject.org/wiki/Features/Gnome3
19:22:35 <nirik> .fesco 497
19:22:36 <zodbot> nirik: #497 (F15Feature: Gnome3 - http://fedoraproject.org/wiki/Features/Gnome3) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/497
19:23:13 <pjones> +1, assuming they manage to pull it off this time.
19:23:16 <kylem> +1. we addressed my questions about it last week when we approved the release cycle.
19:23:19 <cwickert> any feature owners around?
19:23:38 * mclasen_ is around and missing a meeting here at the same time...
19:23:51 * notting is +1
19:24:01 <cwickert> I have some questions on it: what about panel applets?
19:24:22 <mclasen_> the shell doesn't have panel applets
19:24:23 <cwickert> and what about the notification area?
19:24:36 <cwickert> so will all these applet packages need to go?
19:24:40 <mclasen_> it doesn't have that either
19:24:54 <mclasen_> the panel will be around for a while still
19:24:56 <mclasen_> for fallback mode
19:25:14 <cwickert> ok, does it affect anything outside the GNOME desktop?
19:25:15 <mjg59> +1
19:25:30 <cwickert> the libnotify update was pretty inversive
19:25:43 <mclasen_> yeah, that was an example
19:25:57 <mclasen_> notification-daemon is getting some new capabilities, which should not cause problems
19:26:00 <nirik> sure, +1. (I would be happy if someone could write up a way to fallback for those that want to. I suppose using vesa would work, but thats a bit non ideal)
19:26:01 <notting> there is a working list uptream on what to do with the notification area icons of various upstreams
19:26:06 <notting> can't find it at the moment
19:26:14 <mclasen_> gtk3 will give other gtk-based desktop something to do, for porting
19:26:17 <cwickert> what about other notification servers?
19:26:28 <mclasen_> but gtk2 is not going away, so no hurry
19:26:49 <ajax> nirik: the fallback strategy is still a bit of an open question, i'll probably be spending some time on that with owen.
19:27:03 <mclasen_> cwickert: they can either implement the new capabilities, or not - thats what capabilities are about
19:27:12 * rbergeron sees everyone cheering for cloud above and hopes they'll all be coming to the cloud-sig meetings, yo :)
19:27:15 <cwickert> nether knotify nor xfce4-notifyd have the capabilities yet
19:27:21 <nirik> ajax: I bet I will get asked a million times by people in #fedora how to fall back to old gnome if they don't like gnome3.
19:27:25 <kylem> rbergeron, welcome to the team, fwiw
19:27:30 <mclasen_> e.g. the shell itself has them, for its notification server
19:27:33 <gholms> The Team
19:27:35 <nirik> rbergeron: keep up the clouding. ;)
19:27:45 <cwickert> does this mean the notificytions will appear randomly somewhere?
19:27:46 <drago01> notting: http://live.gnome.org/GnomeShell/Design/Guidelines/MessageTray/Compatibility
19:27:53 <mclasen_> cwickert: thats why we recommend that apps actually check for the cababilities before assuming that they are there...
19:27:59 <rbergeron> kylem: thanks. I'll be with y'all as soon as I get this vpn stuff functioning properly :)
19:28:05 <kylem> hehe.
19:28:34 <kylem> nirik, put it in the F15CommonQuestions? :)
19:29:00 <nirik> yep. I just want to note that it would be nice if there was an easy way to do this... ;)
19:29:01 <ajax> nirik: well the answer is 'run desktop-effects and switch', like it is in f13, but there's some interest in trying to wire it up so gnome-shell might be able to work in a software GL environment.
19:29:12 <nirik> ajax: cool, ok.
19:29:16 <cwickert> mclasen_, theses capabilities were guaranteed by libnotify and I haven't seen a discussion on the xdg mailing list before they were removed
19:29:42 <mclasen_> cwickert: not sure I follow, cababilities are something that the server has or doesn't have
19:30:22 <cwickert> mclasen_, yes, but before we could rely on a tray to be present and attach a notification to it. now this is the server#s job
19:30:30 <mclasen_> anyway, we should perhaps take this offline, unless you think it affects the feature directly
19:30:45 <mclasen_> yes, that has changed
19:30:45 <ajax> i'm +1 which i think puts us at +6 (not trying to halt discussion though)
19:31:07 <cwickert> my question is: will this feature affect anything outside of GNOME itself? this is something we need to consider here
19:31:32 <cwickert> I don't see this covered by the feature page
19:32:00 <mclasen_> note that I've only started to update the feature page this morning
19:32:04 <nirik> it's a pile of packages, it could affect other things. I don't know if there is a known list tho.
19:32:24 <mclasen_> I'll make sure to discuss the notification changes
19:32:47 <cwickert> as long as I don't know if/how it affects say Xfce and LXDE, I cannot decide on this feature
19:33:23 <cwickert> it's not that I want slow things down, I just don't want unpleasant surprises
19:33:25 <mjg59> cwickert: Well, us failing to approve the feature doesn't mean the feature doesn't land
19:33:36 <mjg59> It just means we don't relnote it
19:33:53 <drago01> mjg59: *cough* systemd *cough*
19:33:56 <pjones> Was Re: Our feature process sucks.
19:33:58 <mjg59> The libnotify transition has happened in rawhide already. Are other destops broken?
19:34:05 <mclasen_> well, I guess having some discussion about how to land it with managable fallout would be good, I guess
19:34:07 <notting> mjg59: but the point is we're the body that's supposed to handle/ensure there's cross-sig discussion
19:34:19 <nirik> well, I would hope that if there are changes that do affect xfce/lxde the gnome folks will work to mitigate or solve those issues?
19:34:21 <mjg59> notting: Yes, but I don't think that's part of the feature process
19:34:48 <cwickert> mjg59, correct me if I'm wrong, but the package maintainer responsibilities include to avoid breaking other packages and notifying maintainers in question
19:34:48 <mjg59> And in this case we appear to be arguing about something that's already happened?
19:34:48 <mclasen_> cwickert:  any other fallout that you foresee or have noticed already ?
19:35:09 <mclasen_> cwickert: one other thing is that the gio default application lookup has changed
19:35:19 <nirik> the libnotify stuff was pretty easy to patch for... I don't know if it has longer term issues.
19:35:23 * mclasen_ notes that he did notify maintainers before landing libnotify
19:35:33 <cwickert> mclasen_, ok, i missed the announcement on that one (if there was one)
19:36:00 <cwickert> mclasen_, I meant for the gio thing
19:36:24 <mclasen_> that was discussed with the pcmanfm (?) maintainer before landing it, I believe
19:36:37 <cwickert> there was one for libnotify, but it was burried under lots of mails on fedora-devel
19:36:53 <cwickert> note that I know of although I'm co-maintainer of pcmanfm
19:36:59 <ajax> (i have a hard stop at 3, sorry all)
19:37:00 <cwickert> s/note/not
19:37:46 <cwickert> another question: what about updates? will they still get the old desktop?
19:37:50 <nirik> I would say lets approve this and ask mclasen_ to try and notify others of big changes and work with them to mitigate the issues.
19:37:55 <pjones> Does this discussion actually need all of us, or do cwickert and mclasen just need to coördinate?
19:37:59 <pjones> seems like we should move on.
19:38:03 <mclasen_> we'll coordinate
19:38:05 <mclasen_> lets move on
19:38:09 <cwickert> ok ok
19:39:23 <nirik> #topic #498 F15Feature: LessFS - http://fedoraproject.org/wiki/Features/LessFS
19:39:23 <nirik> .fesco 498
19:39:27 <zodbot> nirik: #498 (F15Feature: LessFS - http://fedoraproject.org/wiki/Features/LessFS) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/498
19:40:16 <ajax> the upstream website for this is really offputting
19:40:21 <notting> so, ksm for your disk?
19:40:22 <ajax> check me out, i know design patterns!
19:40:36 <mjg59> I'm not convinced that a fuse filesystem is really going to be more attractive to enterprise users than just buying more storage, but it seems like it may have some niche users and it's a nice technology demonstration if nothing else
19:40:48 <kylem> i like the idea there.
19:41:13 <ajax> it's a cute trick though
19:41:15 <dinnes> Enterprise users are starting to spend huge money on dedupe stuff
19:41:20 * nirik notes max (the package submitter) was moving last weekend/this week.
19:41:31 <ajax> +1
19:41:41 <nirik> zfs has dedup.
19:41:44 <pjones> +1 - seems fine.  not sure how useful it really is, but it's not in the way or something.
19:41:54 <notting> +1. wonder if it will eventually land in the fs, or lvm
19:42:06 <nirik> sure, +1 here... I guess it may be something our users would like to hear about
19:42:09 <pjones> notting: well, btr already has COW stuff...
19:42:11 <kylem> btrfs will grow it i'm sure.
19:42:13 <mjg59> Yeah, +1 even if I suspect this isn't what a long-term solution would look like
19:42:16 <notting> pjones: mooo.
19:42:21 <cwickert> +1
19:42:28 <pjones> notting: exactly.
19:42:30 <cwickert> can somebody please pick up the review?
19:42:33 <nirik> #agreed Feature is approved.
19:42:35 <kylem> +1.
19:42:39 <nirik> cwickert: it's got a reviewer
19:42:50 <cwickert> I doubt tht the current reviewer is capable of doing it properly
19:42:51 <nirik> the submitter is moving, so I don't think he has net access in his new home yet.
19:43:09 <kylem> is the submitter != feature owner? :)
19:43:23 <kylem> 'cause the owner is right here. :)
19:43:51 <kylem> i can't seem to connect to bugzilla right now...
19:43:56 <nirik> correct. Different people.
19:44:06 <nirik> #topic #499 F15Feature: Ocaml3.12 - http://fedoraproject.org/wiki/Features/OCaml3.12
19:44:06 <nirik> .fesco 499
19:44:07 <zodbot> nirik: #499 (F15Feature: Ocaml3.12 - http://fedoraproject.org/wiki/Features/OCaml3.12) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/499
19:44:11 <rwmjones> hello
19:44:44 <nirik> welcome rwmjones
19:44:46 <kylem> +1.
19:44:46 <pjones> +1, sounds nice.
19:44:55 <mjg59> +1
19:44:58 <ajax> "scope" implies there are some packages that are neither simple rebuilds nor upgrades
19:45:10 <ajax> but whatever, that happens for python bumps too
19:45:10 <ajax> +1
19:45:11 <rwmjones> there are ~80 packages, and some are not simple upgrades
19:45:20 <nirik> yeah, +1 here. It looks like it might be a fair bit of updating work, but it would be great to have fedora on the first here. ;)
19:45:22 <pjones> ajax: yeah - but that's not really surprising, it happens with all major language revs.
19:45:30 <cwickert> +1
19:45:39 <kylem> (changing the language with a minor rev of the version numbr seems like a bit of a ... jerk move tho.)
19:45:44 <notting> rwmjones: anything that isn't that is a major loss if it can't be made to work?
19:45:56 <rwmjones> well, it'll be made to work
19:45:57 * notting is +1 in any case
19:45:58 <pjones> kylem: yeah, but not one that us voting against it will change.
19:46:06 <kylem> pjones, indeed.
19:46:09 <mclasen_> +1
19:46:18 <nirik> #agreed Feature is approved.
19:46:24 <nirik> thanks for working on this rwmjones
19:46:28 <rwmjones> np
19:46:40 <nirik> #topic #500 F15Feature: Xfce48 - http://fedoraproject.org/wiki/Features/Xfce48
19:46:40 <nirik> .fesco 500
19:46:42 <zodbot> nirik: #500 (F15Feature: Xfce48 - http://fedoraproject.org/wiki/Features/Xfce48) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/500
19:46:47 <cwickert> +1
19:46:48 <cwickert> :)
19:46:55 <mjg59> +1
19:47:10 <nirik> :) yeah, +1 here too (unless I should recuse myself from my own feature. ;)
19:47:14 <pjones> I'm totally against this :)
19:47:18 <pjones> (but seriously, +1 )
19:47:20 <ajax> +1
19:47:22 <notting> +1
19:47:26 <cwickert> site note: I have packages at http://cwickert.fedorapeople.org/repo/fedora/14/
19:47:31 <kylem> +1, glad you're doing it in a dist tag.
19:47:54 <nirik> cwickert: excellent. was goign to ask where that was.
19:48:14 <nirik> I hope the release really happens this time. ;)
19:48:23 <nirik> #agreed Feature is approved.
19:48:26 <mclasen_> +1
19:48:26 <cwickert> nirik, they are not perfect, but you can mock against them for the thunar-vfs review we need
19:48:47 <nirik> cwickert: cool. Will give a try.
19:48:51 * mdomsch is here in case ConsistentNetworkNaming hasn't come up yet
19:48:57 <nirik> #topic Open Floor
19:48:59 <pjones> mdomsch: it came and went
19:49:00 <kylem> mdomsch, it has. :)
19:49:02 <nirik> mdomsch: it did already. ;)
19:49:15 <mdomsch> ok thanks
19:49:28 <kylem> we approved it but only if you name them 'curly' 'larry' and 'moe' by default.
19:49:33 <nirik> I'll note we have ticket 501 that came up after our agenda was sent out. We can address it next week.
19:49:37 <nirik> .fesco 501
19:49:39 <zodbot> nirik: #501 (Fixing the glibc adobe flash incompatibility) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/501
19:49:40 <mdomsch> --policy=pony
19:49:52 <kylem> nirik, grumble.
19:49:52 <notting> mdomsch: the ponies namespace!
19:50:14 <ajax> i don't mind having a workaround for flash being broken, but changing glibc to do it is just goofy.
19:50:30 * nirik also notes on this a post to the devel list that adobe has a rebuilt flash that has gone to their QA. (no eta on release for it tho)
19:50:31 <pjones> nirik: I propose that we recommend that if you absolutely must use flash, use the 32-bit version with nspluginwrapper
19:50:34 <kylem> yeah, uhm.
19:50:42 <pjones> nirik: since that appears to be the most secure of the bad choices you can make here anyway...
19:50:51 <nirik> well, best case: don't use flash.
19:50:53 <notting> ajax: you want nspluginwrapper to shim an LD_PRELOAD in?
19:50:58 <notting> pjones: they updated the 64-bit one
19:51:04 <kylem> unless we paper over in glibc (which means we hurt the perf of /EVERYTHING ELSE/) there's no really easy way to fix it either.
19:51:06 <pjones> notting: eventually.
19:51:10 <ajax> i mean, we used to have a glibc that would let you do free() on garbage data
19:51:23 * mclasen_ saw a binary patch by halfline that changes all memcpy references to memmap...
19:51:23 <ajax> and we stopped doing that because it was stupid and broken
19:51:28 <nirik> did we want to do a full discussion/decision on this this week? or wait until next?
19:51:43 <pjones> mclasen_: memmove surely?
19:51:52 <notting> mclasen_: that was horrifying and awesome.
19:51:52 <mclasen_> of course
19:51:52 <ajax> full discussion can wait, particularly if there's word of a patch already
19:52:06 <ajax> i was just getting a cheap shot in.
19:52:16 <nirik> the thing that gets me, is that it's unclear if the change in glibc had any advantage.
19:52:20 <pjones> yeah, really i think the answer is to wait and see.
19:52:29 <pjones> sounds like adobe is actually fixing their bug.
19:52:36 <notting> pjones: on a 'months' timeframe
19:52:40 <mjg59> If we want to fix this anywhere ourselves, I think it ought to be in the browser
19:52:48 <mjg59> notting: Latest update on the thread is more optimistic
19:52:48 <pjones> nirik: indeed.  but at the same time, I'm wildly in favor of letting the glibc guys maintain glibc.
19:52:54 <pjones> because you know what job I don't want?
19:53:03 <kylem> mjg59, i'm inclined to agree.
19:53:04 <ajax> grub maintainer?
19:53:12 <pjones> ajax: ugh.
19:53:13 <nirik> ha
19:53:19 <nirik> ok, anyone have anything for open floor?
19:53:27 <kylem> though, papering over it in ld.so if the shlib name is libflashplayer would be fun too.
19:53:31 <ajax> nothin' from me
19:53:36 <mjg59> Nope
19:54:30 * nirik will close out the meeting in a minute if nothing else comes up.
19:54:34 <kylem> another reminder that we've got a fesco election townhall tomorrow at 10AM EST/1500UTC.
19:54:43 <kylem> while we have a captive audience. ;-)
19:54:59 <pjones> yep
19:55:16 <nirik> Thanks for coming everyone!
19:55:22 <nirik> #endmeeting