17:01:35 <notting> #startmeeting FESCO (2012-07-16)
17:01:35 <zodbot> Meeting started Mon Jul 16 17:01:35 2012 UTC.  The chair is notting. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:35 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:42 <notting> #meetingname fesco
17:01:42 <zodbot> The meeting name has been set to 'fesco'
17:01:50 <notting> #chair notting nirik mjg59 mmaslano t8m pjones mitr limburgher jwb
17:01:50 <zodbot> Current chairs: jwb limburgher mitr mjg59 mmaslano nirik notting pjones t8m
17:01:50 <notting> #topic init process
17:02:05 * nirik is here.
17:02:05 <notting> mjg59 and pjones will (theoretically) not be joining us today
17:02:19 <mitr> Hello
17:03:10 <nirik> limburgher may or may not be here.
17:03:32 <notting> heisenburgher?
17:03:43 <gholms> Heh
17:03:49 <pjones> yeah, really not here for this meeting.
17:04:59 <t8m> hello
17:05:34 * limburgher is or is not here
17:05:41 <limburgher> notting: +1
17:05:59 <limburgher> please try not to collapse my waveform.
17:06:13 <t8m> do not open the box
17:06:37 <notting> that's 5. jwb?
17:08:27 <notting> mmaslano was on holiday last week, and appears to be not around this week (still on holiday?)
17:10:06 <mitr> notting: should still be on PTO today
17:11:28 <notting> ok, that's 5 and jwb can join if he's around
17:12:13 <notting> #topic #889 	Retire orphaned packages only after co-maintainers have been notified as it happens in the nonresponsive maintainers procedure
17:12:13 <notting> .fesco 889
17:12:18 <zodbot> notting: #889 (Retire orphaned packages only after co-maintainers have been notified as it happens in the nonresponsive maintainers procedure) – FESCo - https://fedorahosted.org/fesco/ticket/889
17:13:43 <notting> this is a request to at least notify comaintainers when we go through the orphan packages each release
17:13:52 <notting> as i've been doing this, i can do so unless people object
17:13:57 <t8m> +1
17:14:07 <t8m> I think it is reasonable request.
17:14:13 <nirik> the request seems to be to notify them as much as if they were unresponsive?
17:14:25 <nirik> ie, 3 weeks, a bug, a post to devel list, etc.
17:14:35 <t8m> I do not understand it like that.
17:14:54 <notting> i would prefer not to go through bugs - we have posts to devel list, and they can be informed as a cc/adjunct to that
17:14:58 <nirik> "Therefore I suggest to require at least the same amount of communication attempts with co-maintainers when their package is to be retired as it is required for the non-responsive maintainer policy."
17:15:12 <notting> ideally, in the future we could just reassign packages, but, as said by toshio, that's not an option right now
17:15:15 <mitr> Well, tne non-responsive maintainer policy doesn't mention comaintainers at all
17:15:42 <nirik> I'd personally be fine just ccing them on any posts to devel/notices of things that will be orphaned.
17:15:49 <t8m> nirik, +1
17:16:19 <notting> nirik: <acct>@fedoraproject.org good enough, or should i look up bz e-mails?
17:16:25 <mitr> nirik: sounds nice - ultimately this depends on what notting wants to do
17:16:32 <abadger1999> yeah -- admins can reassign to specific people, general people cannot.  admins would still have to lookup who the comaintainers are.
17:17:12 <nirik> notting: I would say that should be good enough...
17:17:51 <notting> ok.
17:18:07 <nirik> is there some way on commits we could warn about orphaned state?
17:18:13 <notting> proposal: i will cc comaintainers (via either <acct>@fedoraproject.org, or bz e-mail from fas) on orphan mails
17:18:25 <mitr> +1
17:18:28 <t8m> +1
17:18:42 <nirik> sure, +1 to that
17:19:19 * notting is implicitly +1
17:19:34 <limburgher> +1
17:20:29 <notting> #agreed notting (or other person doing this task) will CC: comaintainers on orphan mails
17:21:11 <jwb> i am here now.  my apologies for being late
17:21:49 <notting> nirik: we'd need some sort of check on git push. might be worth talking over with dist-git maintainers
17:22:17 <nirik> yeah, thinking about it, not sure how possible it would be... but might be a nice thing if we could work it out.
17:22:50 <nirik> just a 'echo "This package you are commiting to is orphaned, if you are pushing changes to it, you should consider taking ownership in pkgdb" or something.
17:23:22 <nirik> anyhow, can investigate that.
17:23:24 <notting> ok
17:23:26 <jwb> you'd have to poke pkgdb from the client if you're doing it on commit
17:23:41 <jwb> push side could be done with a server side pkgdb query
17:23:45 <jwb> and would impact people less
17:24:55 <notting> feature time...
17:25:02 <notting> #topic #890 	F18 Feature: KDE Plasma Workspaces 4.9 - https://fedoraproject.org/wiki/Features/KDE49
17:25:03 <notting> .fesco 890
17:25:04 <zodbot> notting: #890 (F18 Feature: KDE Plasma Workspaces 4.9 - https://fedoraproject.org/wiki/Features/KDE49) – FESCo - https://fedorahosted.org/fesco/ticket/890
17:25:29 <nirik> +1 here
17:25:36 <notting> auto-desktop-env-update +1
17:25:45 <t8m> +1
17:25:56 <mitr> +1
17:26:14 <jwb> i have no real objections i guess.  +1
17:27:02 <limburgher> +1
17:27:09 <notting> #agreed feature KDE Plasma Workspaces 4.9 is approved (+:6, -:0, 0:0)
17:27:28 <notting> #topic #891 	F18 Feature: Eucalyptus - https://fedoraproject.org/wiki/Features/Eucalyptus
17:27:28 <notting> .fesco 891
17:27:32 <zodbot> notting: #891 (F18 Feature: Eucalyptus - https://fedoraproject.org/wiki/Features/Eucalyptus) – FESCo - https://fedorahosted.org/fesco/ticket/891
17:27:57 <nirik> +1
17:28:07 <nirik> (add to the stable of cloud cloud cloud)
17:28:08 <t8m> +1
17:28:12 <gholms> Heh
17:28:21 <jwb> "...but it does does contain all transitive build..."
17:28:30 <mitr> +1
17:28:30 <jwb> should that be "does not"?
17:28:34 <limburgher> +1
17:28:40 <notting> +1 from me
17:28:48 <gholms> jwb: Looks like it to me.
17:29:03 <jwb> +1 i guess
17:29:37 <gholms> Fixed
17:29:42 <notting> #agreed feature Eucalyptus is approved (+:6, -:0, 0:0)
17:29:56 <notting> #topic #892 	F18 Feature: GNOME IBus Integration - https://fedoraproject.org/wiki/Features/GNOMEIBusIntegration
17:29:56 <notting> .fesco 892
17:29:57 <zodbot> notting: #892 (F18 Feature: GNOME IBus Integration - https://fedoraproject.org/wiki/Features/GNOMEIBusIntegration) – FESCo - https://fedorahosted.org/fesco/ticket/892
17:31:09 <t8m> What about the Ctrl+Space issue?
17:31:12 <nirik> there's one unanswered question on the talk page.
17:31:32 <mitr> I put it there about a hour ago, so...
17:31:55 <mitr> My reading of the feature page is that this does _not_ enable ibus for non-IM locales, but that the mechanisms of im-chooser are TBD
17:32:23 * nirik nods
17:32:24 <mitr> So, should be OK, but I don't know for sure
17:32:46 <jwb> i really don't understand why this is a feature
17:32:47 <notting> prodded some desktop people, but don't know if they're in front of irc. will wait a minute or three
17:33:06 <jwb> it's just making something that was already provided 2 releases ago the default?
17:33:07 * mclasen appears
17:33:21 <limburgher> I'm unclear, is any of this upstream work or Fedora-spcific integration?  #didn't read it all
17:33:34 <drago01> limburgher: upstream
17:33:36 <mitr> jwb: No, it changes the implementation from a separate applet to gnome-shell integrated code IIUC
17:33:36 <notting> limburgher: it's upstream work. (and woo, are those fun threads)
17:33:44 <notting> mclasen: question is from https://fedoraproject.org/wiki/Talk:Features/GNOMEIBusIntegration
17:33:57 <jwb> mitr, but functionally it's the same, yes?
17:34:12 <limburgher> drag01, notting:  Gotcha.  I can imagine. :)
17:34:17 <mclasen> originally, we planned to run ibus by default, but it has since been changed
17:34:19 <t8m> Does it mean that the Ctrl+Space keystroke will be taken over by ibus by default for all locales, or not?
17:34:33 <mitr> jwb: I have difficulty parsing the part that starts with "need to resolve some problems".
17:34:34 <mclasen> we're now only running ibus when input methods are configured
17:35:07 <notting> ok. +1 from me
17:35:09 <mclasen> wrt to Ctrl+Space, we're going to provide ui for configuring those key combinations
17:35:19 <mclasen> thats not quite there yet, but next on the list
17:35:49 <t8m> but by default for locales that do not need input methods, will the ctrl+space be taken over by ibus or not?
17:35:55 <mitr> mclasen: UI for "unbreak my desktop"?
17:36:03 <mitr> what t8m asked
17:36:27 <mclasen> t8m: not so much tied to locales but to whether you have input sources configured that require ibus
17:36:36 <mitr> (as an aside, having a cross-desktop agreement on what keys/modifiers belong to applications vs. the UI is a nice dream)
17:36:54 <nirik> +1 here... I guess this could be notable/important to ibus/gnome3 users
17:37:24 <drago01> mitr: some of them are even cross plattform (ctrl-space thing) so ....
17:37:34 <mitr> mclasen: So, to summarize, ibus will be run by default in the same locales as in F16, correct?
17:38:39 <mclasen> what I said above is a bit more accurate than that; I don't think that we have any connection to locales atm
17:39:50 <mitr> mclasen: F17 has _im_language_list in /etc/X11/xinit/xinitrc.d/50-xinput.sh
17:40:08 <mclasen> yeah, we're not going to rely on that
17:40:44 <mclasen> but we should investigate locale-specific defaults. I'll bring that up with the people working on this
17:41:01 <mitr> Proposal: approve conditional on not using Ctrl+Space for any locales don't currently use it?
17:41:04 * t8m is still confused, whether the users who do not need ibus will be affected or not
17:41:22 <notting> mitr: -1
17:41:36 <mclasen> if you don't need input method, and are negatively affected, then thats a bug
17:41:50 <mitr> notting: objecting to the requirement, or to the mechanism of approval, or to something else?
17:42:27 <notting> mitr: locking the approval into some assumption that whatever the current ibus-using locales are is empirically correct
17:42:34 <mclasen> mitr: if you have a particular aversion to input methods claiming Ctrl-Space, we've documented several ways of exterminating ibus support from gnome 3.6 here: http://live.gnome.org/ThreePointFive/Features/IBus
17:43:04 <mitr> notting: No, it's "ctrl-space-using locales".  The requirement is technology-agnostic
17:43:34 <mitr> but, empirically, I would think that the current default set is correct enough (i.e. there haven't been complaints from the users of the IM locales AFAIK)
17:43:54 <mitr> mclasen: The aversion to claiming Ctrl-Space in locales like en_US is fairly stron, yes
17:44:20 <mitr> See https://fedorahosted.org/fesco/ticket/798 and related discussions
17:44:30 <mclasen> we could just make emacs conflict with ibus :-)
17:44:58 <mitr> mclasen: ... and eclipse?
17:47:10 <nirik> provided there's ways to easily disable it, and/or remap it's keys (which it sounds like to me), and/or to just not have it on by default where it isn't needed... I don't see the issue?
17:47:33 <notting> mitr: what is your concern, exactly? afraid that ibus will be turned on behind your back, or...?
17:48:02 <t8m> mclasen, can you please make it more clear to me what happens in this situation? "I am user from Europe or America who does not need any IM and I install Fedora w Gnome and Eclipse. Will Ctrl+Space work in Eclipse or will not?"
17:48:17 <mitr> notting: If we are making the decision that the desktop environment owns Ctrl-Space from now on, I'd like to know that we are making that decision.
17:48:34 <t8m> mitr, +1
17:48:37 <notting> well, we just approved KDE which for all i know maps ctrl-space to "rm -rf"
17:49:28 <mclasen> mitr: I have to look up what the current proposal is for the keybindings to switch input sources; give me a minute
17:49:41 <nirik> "in any new feature submission, please add a map of all keys used" :)
17:49:43 <mitr> notting: Reading all of the above, I'm just absolutely not clear whether ibus will be running in all locales or not, AFAICT the configuration UI doesn't exist (and I argue that it shouldn't be needed for the western european locales)  Perhaps I just don't know enough
17:50:05 * gholms rings the 20 minute bell
17:50:15 <jwb> i have no concerns about crtl+space equating to anything at all, but i'm still missing where this is feature-ish, particularly when ibus is still only started in locales it was started in on f16.  at the moment, i'm very +0
17:50:18 <drago01> well there is no reason why ibus must "eat" the events
17:50:32 <mitr> Well, we have had #798 raised to us, and sort of punted on that the last time because by saying that the locale-specific default is fine.
17:51:04 <notting> my understanding is that ibus takes it when it's running, and doesn't when it's not. it's a stock input method keysym which seems very much in line with both upstream and users-of-IM-expectations
17:51:05 * nirik supposes we could punt a week on this one and ask for more info in ticket/on talk page for those with concerns?
17:51:05 <mitr> jwb: The https://live.gnome.org/ThreePointFive/Features/IBus design implies ibus runs all the time, perhaps
17:51:35 <mclasen> mitr: as I explained, that was the original approach, but it was changed
17:52:04 <mclasen> I'll go over the document and update it; quite honestly, I wasn't aware the feature was going to be on todays agenda, and am not really prepared...
17:52:23 <mitr> yeah, I should have looked at this eariler as well :(
17:52:25 <t8m> Then please can we punt to next week?
17:52:39 <limburgher> +1 to punting
17:52:50 <mitr> why not
17:52:50 <notting> if you don't want to provide a vote, we have no other option than to postpone, so...
17:52:57 <t8m> +1 from me to punt of course
17:52:59 <notting> #info postponed to next week
17:53:14 <notting> #topic #893 	F18 Feature: GSS Proxy - https://fedoraproject.org/wiki/Features/gss-proxy
17:53:14 <notting> .fesco 893
17:53:15 <zodbot> notting: #893 (F18 Feature: GSS Proxy - https://fedoraproject.org/wiki/Features/gss-proxy) – FESCo - https://fedorahosted.org/fesco/ticket/893
17:54:30 <t8m> Not sure why this is a feature as this seems to be completely transparent change but nevertheless +1
17:54:33 <notting> gd: nfs-utils maintainer is aware of this, yes?
17:54:46 <limburgher> +1
17:54:53 <gd> notting: simo is talking with them, AFAICT.
17:54:56 <nirik> sure, +1.
17:55:19 <jwb> are there kernel options that need to be enabled for this to work?
17:55:31 <gd> notting: providing the infrastructure as a first step does not dirsturb anyone.
17:55:40 <notting> gd: they can both run in parallel?
17:55:50 <gd> notting: yes.
17:56:05 <mitr> Does this mean one more daemon running in the default config, btw?
17:56:15 <mitr> not that it would be a deciding factor
17:56:22 <gd> mitr: no, not unless you want to use it and enable it.
17:56:49 <mitr> +1
17:57:13 * notting is +1
17:58:19 <jwb> gd, are there kernel options that need to be enabled for this to work?
17:58:56 <gd> jwb: I guess the kernel consumers will end up having their old mechanisms around and only use gssproxy when running. For sure no admins or users need to make any changes in order to benefit from gssproxy manually.
17:59:09 <gd> jwb: simo might have more details but he is not here yet.
17:59:23 <gd> s/might have/has/
17:59:55 <jwb> let me put it this way: if there are kernel options that either need to be enabled or remain enabled for this to work, this page needs to list them.  otherwise the kernel team my be apt to turn it off
18:00:03 <jwb> aside from that, +1
18:00:10 <notting> #agreed feature GSS Proxy is approved (+:6, -:0, 0:0)
18:00:11 <jwb> s/my/may
18:00:24 <notting> #topic #894 	F18 Feature: ibus-libpinyin - https://fedoraproject.org/wiki/Features/ibus-libpinyin
18:00:24 <notting> .fesco 894
18:00:32 <zodbot> notting: #894 (F18 Feature: ibus-libpinyin - https://fedoraproject.org/wiki/Features/ibus-libpinyin) – FESCo - https://fedorahosted.org/fesco/ticket/894
18:00:58 <notting> seems like a straightforward swap. +1
18:01:00 <t8m> +1
18:01:12 <mitr> +1
18:01:16 <jwb> +1
18:01:55 <limburgher> +1
18:02:10 <nirik> +1
18:02:22 <notting> #agreed feature ibus-libpinyin is approved (+:6, -:0, 0:0)
18:02:33 <notting> and lastly
18:02:35 <notting> #topic #895 	F18 Feature: Ibus-Typing-Booster - https://fedoraproject.org/wiki/Features/Typing-Booster
18:02:35 <notting> .fesco 895
18:02:37 <zodbot> notting: #895 (F18 Feature: Ibus-Typing-Booster - https://fedoraproject.org/wiki/Features/Typing-Booster) – FESCo - https://fedorahosted.org/fesco/ticket/895
18:03:05 <jwb> out of curiosity, is there a reason all of these ibus features are split out?
18:03:21 <jwb> it seems we could have a single 'improved ibus support' feature to cover them
18:03:24 <notting> they're all separate upstream things that plug into ibus, afaik
18:03:25 <limburgher> WHy not just make an Ibustravaganza?
18:03:35 <gholms> Heh
18:04:02 <mitr> jwb: ISTM that it's useful to announce specifically that Chinese users may benefit from $this improvement, or that $language users may benefit from $that improvement, even if they don't know what ibus is
18:04:24 <notting> and the gnome thing is really more work-in-gnome than work-in-ibus
18:04:25 <jwb> yeah, you can do that with release notes
18:04:40 <mitr> jwb: Yeah, that's what these features are.
18:04:42 <nirik> so, this is a expansion of the f17 feature for english ibus typing booster
18:05:12 <nirik> https://fedoraproject.org/wiki/Features/english-typing-booster
18:05:16 <jwb> mitr, maybe what the process is for some.  not what a Feature is supposed to be.  anyway, larger issue for which we have an open ticket not on today's agenda
18:05:43 <limburgher> +1 in whatever form
18:05:59 <mitr> +1 as well
18:06:04 <nirik> I guess +1
18:06:08 <t8m> +1
18:06:15 <notting> +1 from me
18:06:20 <jwb> i have no real objections with the particular feature.  +1 i guess
18:06:36 <notting> #agreed feature Ibus-typing-booster is approved (+:6, -:0, 0:0)
18:06:40 <notting> now onto...
18:06:42 <notting> #topic Open Floor
18:06:59 <notting> #info mass rebuild for F-18 scheduled to start this week (Wednesday)
18:07:38 <jwb> there was some concern with x86 C++ abi, right?
18:07:53 <notting> new gcc landed today that should fix it
18:08:00 <jwb> ok, great
18:08:26 <limburgher> Is there an info page for common issues like mdomsch has done in the past?
18:08:31 <nirik> as a note for those that haven't seen it there's a article on lwn about rawhide. jon corbett is moving away from it. Not sure if we want to look at adjusting anything with rawhide, but might be something to look at.
18:08:34 <limburgher> and others?
18:08:47 <jwb> nirik, from today?
18:08:51 <nirik> yeah, this morning.
18:08:54 <jwb> hm
18:09:37 <nirik> The big concern seems to be just how few folks are using rawhide day to day anymore. Many developers just jump from stable to branched and don't put much energy into rawhide.
18:09:41 <notting> limburgher: jakub usually tries to categorize failures, but this rebuild is for non-gcc changes aside from the ABI fixes (compressed debuginfo, minidebuginfo)
18:09:58 <jwb> nirik, we've seen similar, yes
18:10:08 <notting> nirik: so, the question is... is that a problem?
18:10:23 <jwb> it's a problem if we want rawhide to be useful
18:10:24 <nirik> perhaps.
18:10:26 <limburgher> notting: thanks.
18:10:57 <notting> jwb: useful as what, though - as a build base doesn't require people running it, for example
18:11:03 <nirik> anyhow, we don't need to discuss it now, but it's something to look into/think about.
18:11:17 <limburgher> I sort of feel like rawhide and branched serve two distinct and important functions, and as long as people are on branched I don't think it's a huge issue.
18:11:37 <mitr> I think we primarily want it to be useful as a place to test feature integration - but that doesn't necessarily require having it be useful _every_ day, only frequently enough.
18:12:29 <nirik> if it's not being used, no one will notice the integration problems?
18:12:31 <jwb> if we're fine with it being a build base and branched is where things really get worked out and fixed, then sure.  it does sort of disprove the 'rawhide keeps rolling' thing though
18:12:51 <mitr> nirik: right, that's a risk
18:12:54 <jwb> rawhide rolls until branched, then it gets ignored
18:14:16 * nirik nods. anyhow, just thought I would bring it up. Feel free to discuss on list. ;)
18:15:09 <notting> anything else?
18:15:17 <notting> if not, will close meeting in 2 minutes
18:15:51 <jwb> just a note that i opened a ticket about refining the feature process.  i'd love comments there, even if they're of the form "you're crazy.  the process is fine"
18:16:17 <mitr> jwb: The Fixing Features page linked in that ticket IIRC leaned towards a quite definite direction
18:16:38 <mitr> and yeah, fixing the process would be great
18:16:43 <notting> #info see https://fedorahosted.org/fesco/ticket/896 for discussion on Fixing The Feature Process
18:16:50 <jwb> yes, i haven't had a chance to actually get back to it today after i filed it last week.  it's on my agenda for this evening
18:18:18 <notting> thanks everyone!
18:18:20 <notting> #endmeeting