13:58:53 <rdieter> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-03-16
13:58:54 <zodbot> Meeting started Tue Mar 16 13:58:53 2010 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:58:55 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:58:57 <rdieter> #meetingname kde-sig
13:58:58 <zodbot> The meeting name has been set to 'kde-sig'
13:59:20 <rdieter> #topic roll call
13:59:26 <rdieter> who's around today ?
13:59:39 * jreznik is here
14:00:23 <SMParrish> I'm here
14:00:51 <Kevin_Kofler> Present.
14:01:04 <rrix> moin
14:01:29 <rrix> Note: I'll be in and out for the meeting, as will mchua (hi!) beause we are filming b-roll for the FAD
14:01:38 <rdieter> hot
14:01:58 <jreznik> b-roll?
14:02:00 * Sho_ is lurking
14:02:08 <Sho_> jreznik: b-roll = optional footage
14:02:28 <rdieter> alright, let's roll
14:02:43 <rdieter> #topic agenda
14:02:50 <rdieter> any topics to add to https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-03-16#Agenda ?
14:02:57 <rrix> yeah
14:03:34 <Kevin_Kofler> Which ones? :-)
14:03:37 <rrix> I talked to spevack and stickster_afk about a few things yesterday that we can do to get better kde integration in the dvd and liveimage and first boot
14:03:46 <rrix> just want to blah about it :)
14:03:57 <rrix> with a "do you want to help
14:04:02 <rrix> " at the end.
14:05:02 <rdieter> #topic rrix blah'ing about dvd/liveimage kde-integration
14:05:08 <rdieter> rrix: ok, blah away.
14:05:10 <rrix> oh the noes
14:05:29 * than is present
14:05:37 <rrix> okay, so yesterday at lunch, the topic came up on how we can improve Fedora KDE's stance among developers and users
14:06:07 <rrix> the consensus was "hey Fedora isn't really seen enough as a KDE distro as opposed to kubuntu or oopensuse, even though we arguably have a better distro"
14:06:44 <rrix> so, basically, it was posited that we rely too much on the live image, and don't use the DVD. Which, i explained was for known and much complained about reasons
14:07:09 <Kevin_Kofler> But Kubuntu also relies on the live image.
14:07:10 <rrix> well, stickster_afk told me that colin walters was looking at fixing that, and looking for help.
14:07:21 <Sho_> i think that's a fishy argument because in my experience most people go only for the live images today, anyway
14:07:30 <Kevin_Kofler> In fact, Kubuntu basically IS the live image, there's an alternate (also KDE-only) CD, but everyone uses the live image.
14:07:32 <Sho_> kubuntu basically only has a live image, and opensuse's has proven popular, too
14:07:52 <rrix> Sho_ Kevin_Kofler: it wasn't really a point we made saying "this is why they're better" only a way that we could improve upon ours.
14:08:10 <Kevin_Kofler> But yeah, the DVD needs fixing.
14:08:10 <Sho_> well sure, as long as the DVD doesn't go away, improving it is a good idea
14:08:21 <Sho_> we want people to have a good time no matter which medium they pick, of course
14:08:24 <rrix> Kevin_Kofler: well, anyone wanting to help should mail walters@redhat.com :)
14:08:41 <rdieter> rrix: any details on it?  or I guess we can just fine out...
14:08:43 <jreznik> what we need to improve DVD? comps?
14:08:48 <rrix> comps, yeah
14:09:11 <rrix> comps and splitting a few of the default packages so they don't pull in gnome-world
14:09:16 <Kevin_Kofler> Re firstboot, the main issue there is that it requires metacity.
14:09:24 <rrix> Kevin_Kofler: and I was coming to that now :)
14:09:25 <Kevin_Kofler> This also bloats our live images with unwanted dependencies.
14:10:16 <Kevin_Kofler> Was any solution suggested?
14:10:34 <rrix> Kevin_Kofler: notting brought up a few days ago (says stickster_afk, i haven't looked) that they were looking at creating a way for firstboot (and eventually anaconda if necessary) to use another window manager besides metacity. it shouldn't be /too/ hard to do i'd imagine
14:10:45 <rrix> lenmme grep the list
14:10:46 <jreznik> hh, we should split packages to not pollute gnome word - we can do it... ask gnome folks for same :(
14:10:56 <Kevin_Kofler> I'd suggest making it support kwin as well and having it require a virtual Provides provided by metacity and kdebase-workspace instead of metacity directly.
14:11:14 <Sho_> (gotta step out for a moment, ping me when the qt 4.7 topic comes up though, got my 2ct on that)
14:11:25 <jreznik> anaconda team is already working on metacity replacement
14:11:34 <Kevin_Kofler> But maybe doing away with requiring desktop WMs entirely and make it use some small minimalist WM is the best solution.
14:12:25 <rrix> eh, I can't find it
14:12:33 <Kevin_Kofler> Both Metacity and KWin can be used standalone, but aren't really designed for that use. Plus, Metacity is deprecated in GNOME now that gnome-shell is coming.
14:12:38 <rdieter> ok, sounds good.  Can we have someone from our team willing to be comps-kde-czar and lead these coordination efforts?
14:13:12 <jreznik> what's actually our target for comps?
14:13:21 <rrix> I can get with walters, after we discuss what we want
14:13:43 <jreznik> does it mean different comps? some selection in Anaconda to choose DE?
14:13:48 * rdieter dubs rrix, sir comps-kde-czar , be brave and strong
14:13:50 <Kevin_Kofler> I don't know what walters imagines. My idea is to have a desktop selection screen like in OpenSUSE prepended to the package selection and to have conditionals based on DE in comps.
14:14:07 * mchua here, lurking
14:14:13 <Kevin_Kofler> But walters may be thinking of something different.
14:14:17 <rdieter> we'll have to see how thigns develop as the details roll in
14:14:31 <rdieter> mchua: hi!
14:14:32 <rrix> I'll get with him in the next day hopefully
14:14:41 <rrix> will be busy Doing Awesome Things today, but
14:14:46 <rrix> eh, brb, sec
14:14:58 <rdieter> Sho_: ping, if you're around, we can do qt-4.7.0 next
14:15:14 <Sho_> ok
14:15:24 <rdieter> #topic qt-4.7.0-tp ready for devel/ import
14:15:37 <Sho_> so I've been running Qt 4.7tp1 on F12 for a few days now, via rex' packages
14:15:45 <rdieter> I've got a first crack at packaging qt-4.7.0-tp done.
14:16:05 <Kevin_Kofler> IMHO we should get this into Rawhide ASAP.
14:16:07 <rrix> awesome!
14:16:15 <Sho_> the only problem I've had is a build problem with Amarok git master, which was their fault since they were doing something stupid, namely initializing QStrings with ints (i.e. QString foo(0) basically) which 4.7 no longer likes due to changed constructors
14:16:16 <rrix> If it's not horribly broken ship it to rawhide!
14:16:18 <Kevin_Kofler> The qt-assistant-adp compat package is now imported (but not built yet).
14:16:51 <Sho_> I fixed that in their git, but it was probably after the 2.3.0 tag, so if they do 2.3.1 from a branch rather than master and don't backport it, amarok 2.3.1 might have trouble building with 4.7 or so
14:16:51 <rdieter> my only/primary concern is that this will inevitably leave PyQt4/PyKDE4 broken
14:16:58 <Sho_> other than that, the experience has been regression-free for me
14:17:10 <Kevin_Kofler> Re qt-assistant-adp, should we keep the < versioned Conflicts (which are more correct) or use >= versioned Requires instead?
14:17:10 <than> i don't see any problem to ship 4.7 in rawhide
14:17:13 <Sho_> it's also been fix-free (e.g. the disappearing mouse cursor bug that entered the scene in 4.6.0 is still there)
14:17:50 <rdieter> Kevin_Kofler: I'd prefer the versioned requires myself
14:17:56 <Kevin_Kofler> The Conflicts are really correct because it really does conflict with the old versions of Qt.
14:18:03 <Kevin_Kofler> But Requires will have almost the same effect.
14:18:44 <rdieter> ok, looks like we have no dissenters, let's do it then
14:19:03 <Kevin_Kofler> I noticed qt4-x11 is not provided with ISA, let's please fix that for 4.7 so I can Require qt4-x11%{?_isa} >= 4.7.
14:19:07 <rdieter> I'll commit and get builds going after the meeting.
14:19:24 <rdieter> doing just qt4 dep should be sufficient
14:19:49 <rdieter> -x11 will get pulled in implicitly, and it has versioned requires to make sure things are sane
14:20:18 <Kevin_Kofler> Yeah, OK.
14:20:56 <rdieter> #action rdieter to commit/build qt-4.7.0-tp1 in devel/
14:21:06 <rdieter> #topic kde-4.4.1 status
14:21:29 <rdieter> well, our week passed, and -testing has been good I think.
14:21:40 <Kevin_Kofler> Yeah, let's please push this to stable now.
14:21:47 <Kevin_Kofler> We've been sitting on it for way too long.
14:21:59 <Kevin_Kofler> And future bugfix releases should be pushed out much faster.
14:22:07 <SMParrish> No issues here so I'm good for a push to stable
14:22:14 <rdieter> patience.
14:22:29 <rdieter> but here, indeed, +1 stable
14:22:32 <Kevin_Kofler> 4.4.1 fixes some regressions in 4.4.0. Hopefully that SIGBUS we're getting abrt-spammed with should be fixed too in it.
14:22:46 * rrix nods
14:22:47 <rdieter> than?
14:22:54 <rrix> +1 to stable
14:22:59 <than> +1 from me
14:23:14 <ltinkl> +1 too
14:23:16 <jreznik> I'm using 4.4.1 on all of my systems, looks ok, much more stable than 4.4.0 (from abrt perspective)
14:23:18 <jreznik> +1
14:23:25 <rdieter> #agreed kde-4.4.1 is ready for stable updates
14:23:48 <rdieter> #topic triaging trips/tricks for commonly reported abrt bugs?
14:23:50 <Kevin_Kofler> I'm pushing it to stable right now.
14:24:12 <rdieter> speaking of abrt bugs, we're gettings lots of dups, Kevin_Kofler's been very good at catching/triaging those
14:24:31 <jreznik> rdieter: abrt people are working on dups checker but it's not easy to check kde bt for duplicates
14:24:43 <jreznik> but I'm constantly spamming abrt people with our duplicated
14:24:44 <rdieter> 2 things come to mind for me: 1.  how can we do a better job of triaging these
14:24:44 <Kevin_Kofler> Well, basically I've caught all the dupes of that KPixmapCache bug because they were very easy to recognize.
14:24:47 <jreznik> duplicates
14:24:54 <Kevin_Kofler> SIGBUS is something which never happens otherwise.
14:25:01 <SMParrish> Personally I hate ABRT bugs.  I've been requesting they all go upstream
14:25:04 <Kevin_Kofler> (I did check the backtraces, it was always KPixmapCache.)
14:25:12 <rdieter> 2.  for items with lots of reports/dupes, we should make some official efforts to upstream those
14:25:28 <Kevin_Kofler> SMParrish: That's a big issue indeed, ABRT reporting those bugs to us downstream packagers really sucks.
14:25:36 <jreznik> Kevin_Kofler: do we have some info from upstream? is it fixed?
14:25:46 <SMParrish> Also most reporters never respond so almost 100% are ending up getting closed
14:25:54 <Kevin_Kofler> jreznik: I don't know.
14:26:03 <Kevin_Kofler> Our request to foward the bug upstream got ignored.
14:26:08 <jreznik> Kevin_Kofler: so rdieter is right - we should report it upstream
14:26:09 <Kevin_Kofler> None of the reporters bothered.
14:26:16 <Kevin_Kofler> It may be already fixed in 4.4.1.
14:26:22 <Kevin_Kofler> We should only report it if it's still there.
14:26:31 <Kevin_Kofler> Otherwise we should just close it.
14:26:36 <rdieter> SMParrish: it happens yeah.  that's part of the virtue of having a *little* barrier of bug reporting.  If it's too easy, no feedback.
14:27:04 <rdieter> ok, if we see further dups of these common issues with 4.4.1, then we'll upstream it.
14:27:05 <jreznik> rdieter: upstream is solving this barrier thing too
14:27:16 <jreznik> rdieter: good plan
14:27:36 <rdieter> anything else here? (else I'll move on)
14:27:41 <jreznik> and I try to abuse abrt people with more our dups to maka it working for us ;-)
14:28:01 <Kevin_Kofler> I'm still for removing ABRT from the KDE spin and for autoclosing all ABRT-filed bugs with some form letter (like CLOSED UPSTREAM – please report this issue to the upstream developers, we will not evaluate autogenerated bug reports).
14:29:21 <rdieter> I suppose in a perfect world, ABRT clientside would be accompanied by additional ABRT server/bugzilla side tools to help deal with them all.
14:29:42 <SMParrish> ABRT needs some work but it is here and we have to deal with it
14:29:53 <rdieter> #topic https://fedoraproject.org/wiki/SIGs/KDE/KDE_Target_Audience
14:30:00 <rdieter> ok, now for the fun stuff.
14:30:02 <Kevin_Kofler> I get tons of ABRT reports for Gnash, almost nobody bothers forwarding them upstream when asked.
14:30:15 <Kevin_Kofler> Some won't even retest after a Gnash update.
14:30:23 <jreznik> Kevin_Kofler: if duplicates - send me #bz and I'll forward it to kklic
14:30:33 <Kevin_Kofler> And of course many crashes are not fixed because they aren't getting reported upstream.
14:30:41 <Kevin_Kofler> jreznik: I have no idea whether they are duplicates.
14:30:48 <Kevin_Kofler> I can't compare all the backtraces, they are too many.
14:30:56 <rdieter> over the past few days, I brainstormed a bit what I consider to be our target audience
14:31:01 <Kevin_Kofler> (And some are entirely useless.)
14:31:08 <rdieter> and took input from a few others in #fedora-kde who happened to be around.
14:31:45 <rdieter> Is this close to what other's current perceptions are when it comes to the target audience we're aiming for?
14:31:57 <mefoster> rdieter: What is "this"?
14:32:03 <rdieter> https://fedoraproject.org/wiki/SIGs/KDE/KDE_Target_Audience
14:32:17 <mefoster> oops, sorry, reading comprehension FAIL
14:32:41 <jreznik> rdieter: I don't like it... looking for words how to describe my feelings ;-)
14:32:52 <mefoster> "more control of their desktop" -- more than what?
14:32:56 <rdieter> once we're close to agreeable, then I'd like to RFC from our kde list.
14:33:21 <mefoster> I like the Update SOP, but not sure about the target audience part
14:33:23 <jreznik> I'm not sure our users should be somehow special to fedora users
14:33:29 <rdieter> I didn't particularly like that line as worded either, but I pasted it verbatum from suggestions
14:33:37 <SMParrish> looks like a good start to me
14:34:01 <than> the update SOP looks very good
14:34:07 <rdieter> jreznik: I think it's important to differentiate from other Target audiences being bandied about, because it''s clear (to me) that we don't match
14:34:42 <jreznik> rdieter: now the question is - are we going to have one broad fedora audience or custom spin audience?
14:34:45 <rdieter> I want it clear that our target audiences *do* include developers, contributors
14:34:51 <jreznik> board should decide first...
14:35:04 <Kevin_Kofler> mefoster: More than in other offerings, like proprietary OSes, GNOME etc.
14:35:08 <rdieter> jreznik: the board asked what our opinions are wrt to target audience
14:35:10 <rdieter> this is it
14:35:26 <rdieter> they asks all spin owners, as a matter of fact.
14:35:57 <rdieter> So as-is, that section is probably worded too strongly.
14:36:02 <jreznik> it does not include "joe users", I'm not sure we don't want them
14:36:20 <rdieter> target audience isn't about excluding anyone
14:36:40 <rdieter> it's all about what we are focussing on.
14:36:40 <Kevin_Kofler> They're welcome to use our stuff if they like current flexible software.
14:36:58 <Kevin_Kofler> But we aren't going to dumb down our software or let it rot unupdated just to make them happy.
14:37:11 <Kevin_Kofler> If that's what they want, they should find another solution.
14:37:25 <rdieter> well, I'd phrase in a positive way instead.
14:37:35 <mefoster> rdieter: positivity is good :)
14:37:37 <rdieter> which is what the current document is trying to do
14:37:53 <mefoster> So KDE spin is particularly targeted to people who want cutting-edge updates
14:37:54 <rdieter> I'll take out the line about "more control", its unclear and vague
14:38:00 <Kevin_Kofler> Being current and flexible doesn't necessarily exclude anyone, but sure, if you don't want your menu item to ever move by 1 pixel, then you probably want some other distro. ;-)
14:38:02 <Sho_> I think jreznik's point is that we don't need to make an effort to differenciate our target audience from the audience of the default spin at all, we can define our target audience completely independently of theirs. If there's overlap, that doesn't mean we can't still be doing a better job.
14:38:13 <mefoster> and is of course open to be used by other people but they need to understand what they're getting
14:38:19 <Sho_> If you define yourself in contrast to something else, you automatically create a dependency on that something else
14:38:19 <rdieter> Sho_: agreed
14:38:23 <Sho_> and we don't need that dependency
14:38:28 <ltinkl> rdieter: what about more configurability instead?
14:38:36 <mefoster> I don't like "more" in general
14:38:45 <mefoster> always invites comparisons
14:39:00 <jreznik> Sho_: exactly!
14:39:01 <rdieter> users who value configurability (or is that still too much the same thing?)
14:39:01 <Sho_> We don't really need to justify ourselves … it doesn't need to be part of that document's goals to contrast with anything else
14:39:05 <Kevin_Kofler> What about "full control of their desktop"?
14:39:20 <Kevin_Kofler> That's not a comparison and it gets that point across.
14:39:25 <rdieter> it shouldn't mention desktop at all, imo
14:39:31 <rdieter> it should describe the user
14:39:47 <Kevin_Kofler> "full control of their machine"? ;-)
14:40:18 <rdieter> So, anyone have concrete suggestions on improving the message?
14:40:22 <jreznik> I like you can set KDE to be more "joe user" than gnome could ever be but still let you flexibility to do what you want... this is most exciting!
14:40:32 <Kevin_Kofler> Or to describe the user him/herself: "users who like to be empowered, as opposed to having their computer decide for them".
14:40:48 <jreznik> Kevin_Kofler: but you can do this with KDE too
14:40:51 <rdieter> too negative still for my taste, and drawing comparisions
14:41:06 <jreznik> KDE can be configured both ways
14:41:34 <jreznik> we just need to find some median for our default config
14:41:42 <Sho_> "Users who want their desktops to reflect their preferences to the utmost degree." or something like that
14:41:52 * rdieter likes that
14:42:34 <Sho_> It gets the point across that KDE is highly configurable to a user's personal content, and doesn't make a comparison
14:42:43 <jreznik> Sho_: I like the first part
14:42:43 * rdieter added that one
14:43:04 <Kevin_Kofler> Shouldn't "nitch" be "niche" instead?
14:43:13 <rdieter> probably
14:43:15 <Sho_> rdieter: I agree with jreznik that the "to the utmost degree" is a bit bulky
14:43:19 <jreznik> so "Users who want their desktops to reflect their preferences. PERIOD"
14:43:20 <rdieter> ok
14:43:22 <mclasen> 'tweakers paradise'
14:43:26 <mefoster> yes, "niche" is right
14:43:32 <Sho_> rdieter: "Users who want their desktop to reflext their personal preferences." is probably enough already
14:43:35 <Sho_> *reflect
14:43:38 <rdieter> updated
14:44:05 <rdieter> mclasen: :)
14:44:21 * mclasen is in the wrong meeting...
14:44:23 <Kevin_Kofler> Yeah, we shouldn't exaggerate, we aren't that infamous Beryl-config either.
14:44:24 <jreznik> for example I have really simplistic KDE - we can take a look how to tweak it to our users needs
14:44:42 <rdieter> not sure I like "users who appreciate keeping up with the latest versions ..." either
14:45:01 <Kevin_Kofler> (Newer compizconfig tried to make a bit less of a messy effect, kinda what KDE 4 did to some unwieldy KDE 3 preferences dialogs.)
14:45:21 <jreznik> some preferences in KDE are still big mess...
14:45:28 <Sho_> rdieter: "Users who want access to the latest and greatest KDE has to offer"?
14:45:53 <mefoster> Sho_: that sounds good
14:46:16 <jreznik> mclasen: feel free to join our paradise ;-) beer for free ;-)
14:46:18 <rdieter> the reason I don't like that is because our target audience is defining our policies then (or at least too explicitly for my own taste)
14:46:34 <Sho_> rdieter: that's why I added "and greatest", actually
14:46:49 <Sho_> rdieter: if the latest turns out to suck because we (upstream) went crazy, you can still ship "the greatest" ;)
14:47:00 <rdieter> meh, that's better than what it says now, so...
14:47:31 <rdieter> added, removed commentary on rawhide too
14:47:37 <mefoster> Do we specifically want to mention users who are prepared to be active in testing/filing bugs ...?
14:47:58 <mefoster> But not only -- its more that they want to keep up with upstream developments
14:48:00 <rdieter> maybe, though I had that in mind by targeting contributors/developers already
14:48:05 <mefoster> and we hope upstream doesn't go crazy :)
14:48:37 <SMParrish> I would not mention looking for testers and bug filers.  Might give them the impression we are buggy
14:48:56 <mefoster> SMParrish: good point :)
14:48:58 <jreznik> we are cooking the dog's & cat's cake (one czech tale)
14:49:12 <mefoster> Just stick to "eager to keep up with latest and greatest" or whatever
14:50:06 <rdieter> alright, can everyone refresh the page... so are we close to something we can agree on now?
14:50:07 <jreznik> all buzz now is around "stable" - whatever it means
14:50:35 <rdieter> If so, I'll take it to the list for further comment
14:50:38 <mefoster> Possible can of worms ... do we want to add anything to Update SOP about Fn and Fn-1 and so on
14:50:49 <rdieter> mefoster: not yet, imo
14:50:52 <Kevin_Kofler> s/kde contributor/KDE contributors/
14:51:03 <mefoster> rdieter: fair enough, that can come later on
14:51:03 <Sho_> rdieter: "Users wishing to contribute to KDE development" @ nicer version of "kde contributor"
14:51:16 <jreznik> and I still miss - users who just want workstation to do their jobs
14:51:23 <Kevin_Kofler> and generally s/kde/KDE/g and s/fedora/Fedora/g :-)
14:51:58 <rdieter> ok
14:52:19 <rdieter> maybe should've used gobby/kobby. :)
14:52:22 <Sho_> rdieter: "Users looking for a modern and robust desktop to get their work done" @ jreznik's wish
14:52:38 <Kevin_Kofler> s/a/the most/ ? ^^
14:52:57 <jreznik> Sho_: you are great marketing guy!!!
14:53:02 <Sho_> Kevin_Kofler: we discussed that above ;)
14:53:11 <rdieter> likie, added
14:53:35 <rdieter> we can probably bikeshed about ordering these later too.
14:53:54 <rdieter> put the ones we value most toward the top
14:53:55 <Sho_> yeah, I'd put that last one up top probably
14:54:02 <jreznik> Sho_: +1
14:54:06 <rdieter> me too (that's why I thought of that)
14:54:31 <rdieter> moved to top
14:54:34 <Sho_> robust and modern, personal prefs, latest and greatest would be my top 3 in that order
14:54:57 <rdieter> ok
14:54:57 <jreznik> of course it's not nice to work on something you don't like so contributors should be on top too
14:55:04 <Kevin_Kofler> Sho_: +1
14:55:24 <Kevin_Kofler> Put the advantages for everyone first, then all the items about contributors.
14:55:47 <Sho_> putting Fedora contributors on top of the software devs and KDE contributors probably makes sense in the context of Fedora's meta-goal to empower users to become Fedora contributors
14:56:05 <jreznik> yes
14:56:12 <Sho_> "Software developers" might be redundant with "get their work done"
14:56:28 <rdieter> past the top 3, it's pretty even to me.
14:56:30 <jreznik> contributors should have chance to influence it
14:56:43 <jreznik> it's open source world...
14:58:05 <rdieter> good work everybody, I really like the message now.
14:58:21 <jreznik> so I like "Fedora contributors who want to influence future of Fedora"
14:58:22 <rdieter> looks like we're about out of time, final thoughts?
14:58:44 <Sho_> my one insecurity at this point is that the "get their work done" skews things away from private/personal desktops somehow, not necessarily a bad thing, but KDE is not just a business desktop of course
14:58:52 <jreznik> to say the message - we want people with vision
14:59:09 <rdieter> jreznik: nice, I like empowerment
14:59:36 <jreznik> and we want people to influence what they get
14:59:39 <jreznik> Sho_: you are right
14:59:44 <rdieter> time's up
14:59:47 <rdieter> #endmeeting