===================================
#fedora-meeting: FESCO (2012-07-16)
===================================
Meeting started by notting at 17:01:35 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2012-07-16/fesco.2012-07-16-17.01.log.html
.
Meeting summary
---------------
* init process (notting, 17:01:50)
* #889 Retire orphaned packages only after co-maintainers have been
notified as it happens in the nonresponsive maintainers procedure
(notting, 17:12:13)
* AGREED: notting (or other person doing this task) will CC:
comaintainers on orphan mails (notting, 17:20:29)
* #890 F18 Feature: KDE Plasma Workspaces 4.9 -
https://fedoraproject.org/wiki/Features/KDE49 (notting, 17:25:02)
* AGREED: feature KDE Plasma Workspaces 4.9 is approved (+:6, -:0,
0:0) (notting, 17:27:09)
* #891 F18 Feature: Eucalyptus -
https://fedoraproject.org/wiki/Features/Eucalyptus (notting,
17:27:28)
* AGREED: feature Eucalyptus is approved (+:6, -:0, 0:0) (notting,
17:29:42)
* #892 F18 Feature: GNOME IBus Integration -
https://fedoraproject.org/wiki/Features/GNOMEIBusIntegration
(notting, 17:29:56)
* postponed to next week (notting, 17:52:59)
* #893 F18 Feature: GSS Proxy -
https://fedoraproject.org/wiki/Features/gss-proxy (notting, 17:53:14)
* AGREED: feature GSS Proxy is approved (+:6, -:0, 0:0) (notting,
18:00:10)
* #894 F18 Feature: ibus-libpinyin -
https://fedoraproject.org/wiki/Features/ibus-libpinyin (notting,
18:00:24)
* AGREED: feature ibus-libpinyin is approved (+:6, -:0, 0:0)
(notting, 18:02:22)
* #895 F18 Feature: Ibus-Typing-Booster -
https://fedoraproject.org/wiki/Features/Typing-Booster (notting,
18:02:35)
* LINK: https://fedoraproject.org/wiki/Features/english-typing-booster
(nirik, 18:05:12)
* AGREED: feature Ibus-typing-booster is approved (+:6, -:0, 0:0)
(notting, 18:06:36)
* Open Floor (notting, 18:06:42)
* mass rebuild for F-18 scheduled to start this week (Wednesday)
(notting, 18:06:59)
* see https://fedorahosted.org/fesco/ticket/896 for discussion on
Fixing The Feature Process (notting, 18:16:43)
Meeting ended at 18:18:20 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* notting (73)
* mitr (41)
* nirik (33)
* jwb (33)
* t8m (20)
* limburgher (17)
* mclasen (15)
* zodbot (11)
* gd (7)
* gholms (6)
* drago01 (3)
* abadger1999 (1)
* pjones (1)
* mmaslano (0)
* mjg59 (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
