13:59:46 <rdieter> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-03-09
13:59:47 <zodbot> Meeting started Tue Mar  9 13:59:46 2010 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:59:49 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:04 <rdieter> #chair Kevin_Kofler than SMParrish jreznik
14:00:05 <zodbot> Current chairs: Kevin_Kofler SMParrish jreznik rdieter than
14:00:08 <rdieter> #meetingname kde-sig
14:00:09 <zodbot> The meeting name has been set to 'kde-sig'
14:00:15 <rdieter> #topic roll call
14:00:19 <rdieter> who's present today ?
14:00:28 <Kevin_Kofler> Present.
14:01:07 * than is present
14:02:34 <rdieter> jreznik, ltinkl : ping
14:02:46 * ltinkl just arrived
14:02:52 <jreznik> here
14:03:19 <rdieter> #topic kde-4.4.1 update status
14:03:38 <rdieter> k, looks like we've got 4.4.1 in updates-testing now (as well as kde-testing).
14:03:58 <rdieter> so far so good
14:04:11 <Kevin_Kofler> Looks like no complaints so far.
14:04:31 <Kevin_Kofler> I think we can go stable soon.
14:04:43 <ltinkl> I'm definitely going to test as soon as they arrive
14:04:48 <jreznik> it's working quite well - seems much more stable for me than 4.4.0 (no abrt at all)
14:05:06 <rdieter> I agree, also note in parallel I put out a kde-settings update to enable nepomuk (but not strigi indexing)
14:05:12 <Kevin_Kofler> So, do you want me to hit "push to stable" right away?
14:05:28 <rdieter> wait at least a few more days... :)
14:05:29 <Kevin_Kofler> Or should we wait for at least a week of testing?
14:05:36 <than> Kevin_Kofler: not yet
14:05:41 <rdieter> let's shoot for early next week
14:06:09 <jreznik> next meeting please
14:06:11 <than> Kevin_Kofler: we should wait for a week of testing
14:06:24 <jreznik> I'm testing it on three computers, behaves very well
14:06:26 <Kevin_Kofler> If I hit "push to stable" on Sunday so that it gets pushed next Monday, is that OK?
14:06:44 <Kevin_Kofler> (assuming no negative feedback coming in in the meantime)
14:06:51 * SMParrish late but here
14:06:58 <rdieter> SMParrish: hi :)
14:07:51 <rdieter> Kevin_Kofler: how about waiting until then, and getting say 3 +1's from our informal steering committee folks
14:08:23 <rdieter> f13 stuff perhaps could go earlier though.
14:08:25 <ltinkl> let's informally vote at the next meeting
14:08:36 <than> Kevin_Kofler: let wait for next meeting
14:08:50 <Kevin_Kofler> Next meeting means waiting for more than a week of testing though.
14:09:10 <rdieter> ok, a ocuple more days won't hurt.  (it'll be at least a week + 1 day)
14:09:24 <rdieter> should we treat f13 any different or the same ?
14:09:40 <Kevin_Kofler> But this fixes some regressions in 4.4.0, it's a bugfix-only release and there are no complaints so far.
14:09:48 <jreznik> it's already in kde-redhat for really impatient users...
14:09:49 <Kevin_Kofler> Why does this need 8+ days of testing?
14:10:17 <rdieter> Kevin_Kofler: because it's big that's all.  waiting a few more days gives us the luxery of rolling in other fixes in the meantime as well
14:10:23 <SMParrish> Since alpha just came out today I would say push it out to F13 now, and give F12 & F11 a weeks testing
14:10:30 <rdieter> for example, the kdebindings/mono thing
14:11:16 * thomasj_ is here as well
14:11:21 <Kevin_Kofler> Good point there, but on the other hand rolling in more stuff can cause new problems.
14:11:24 <rdieter> I would tend to agree with SMParrish, anyone else ?
14:11:39 <Kevin_Kofler> Pushing what works to stable and queueing extra stuff later might be safer.
14:11:40 <jreznik> SMParrish: +1
14:12:04 <jreznik> Kevin_Kofler: mono wouldn't cause problems - but I'd like to see it in next push too
14:12:26 <jreznik> (as no one is using mono I hope at all)
14:12:34 <than> SMParrish: +1
14:12:41 <jreznik> but you're right - do not touch this stuff in this push
14:12:41 <ltinkl> plus one
14:13:32 <jreznik> maybe we can have quick "go" meeting earlier in case of no problems arrives but for now it's safer to wait one week
14:13:43 <rdieter> consider us agreed then, we'll do f13 asap, the others wait until next meeting to decide.
14:14:02 <Kevin_Kofler> If it's stable enough for the frozen F13, why is it not stable enough for updates?
14:14:24 <rdieter> #agreed will push 4.4.1 stable soon for f13, f11/f12 decision postponed until next meeting
14:14:49 <jreznik> Kevin_Kofler: it's after alpha, we are not going to ship it soon in F13 again so we have not so pressure to fix possible problems
14:15:01 <ltinkl> Kevin_Kofler: it's good enough for alpha release of F13? :)
14:15:02 <rdieter> F13 is out there for *testing* purposes
14:15:03 <Kevin_Kofler> The Alpha is set to update from the dist-f13 repos.
14:15:04 <Southern_Gentlem> Kevin_Kofler,  you have more people to affect if you break f11-f12 at this point
14:15:10 <SMParrish> Kevin_Kofler: very few people will be running f13 atm, and those who do are expecting issues and will report them.  F12 and F11 expect and want stabilty
14:15:53 <Southern_Gentlem> people running the  alpha will be running it mainly in vm
14:16:06 <thomasj_> +1 Southern_Gentlem
14:16:19 <thomasj_> If KDE breaks this time, they will hang us higher
14:16:24 <Kevin_Kofler> The F13 update is now queued for stable.
14:16:36 <Kevin_Kofler> thomasj_: The point is that 4.4.1 actually fixes some of the breakage from 4.4.0.
14:16:45 <rdieter> ok, anything else, or can we move on?
14:16:52 <Kevin_Kofler> What about rdieter's kde-settings update?
14:16:54 <thomasj_> Kevin_Kofler, i know, but you know what hell is going on at the list right now.
14:16:56 <Kevin_Kofler> When can that go stable?
14:17:19 <Kevin_Kofler> I'd say ASAP, I've been running with Nepomuk enabled since right after I upgraded to 4.4.0, no issues.
14:17:20 <rdieter> oh, ok, sure comments there wrt to enabling nepomuk ?
14:17:39 <ltinkl> no problems with nepomuk here, it actually works :)
14:17:50 <thomasj_> Enabling nepomuk, disabled strigi: +1
14:18:00 <rdieter> just looked, it hasn't actually been pushed into -testing yet, looks like I queue'd it too late for yesterday's push
14:18:07 * thomasj_ tends to forget he has no voting right.. sorry
14:18:10 * ltinkl even has strigi on
14:18:35 <jreznik> ltinkl: problem is with disabled nepomuk, not running one :)
14:18:38 <rdieter> thomasj_: we're not formally voting on anything anyway, doing it that way to express opinions is perfectly ok.
14:18:54 <thomasj_> ltinkl, me too, but i fear a bunch of emails about the resource uasge of strigi if it's enabled out of the blue.
14:19:07 <ltinkl> thomasj_: yup
14:19:21 <Kevin_Kofler> We shouldn't enable Strigi in an update.
14:19:21 <rdieter> since this update hasn't hit testing yet, how about waiting then.  give it at least 2-3 days in -testing, then we'll see.
14:20:01 <rdieter> to be clear,this update does *not* enable strigi indexing. :)
14:20:08 <rdieter> only nepomuk
14:20:11 <thomasj_> :)
14:20:23 <Kevin_Kofler> You had already queued this to testing earlier, why have you unqueued it (and then requeued it too late for the push)? :-(
14:20:38 <Kevin_Kofler> We had already agreed on #fedora-kde that it should be done.
14:20:57 <rdieter> I meant to submit it only for pending before, bodhi queue'd it anyway (maybe my error), so I undid it
14:21:15 <Kevin_Kofler> But why? We already agreed on it, it should have hit testing ASAP!
14:21:26 <rdieter> Kevin_Kofler: really?  I'd been looking around for +1's, and no one was around.
14:21:39 <rdieter> only you, I, and jreznik at the time, iirc.
14:21:40 <Kevin_Kofler> All those who were around agreed. ;-)
14:21:57 <Kevin_Kofler> And that's already almost a formal majority (just one +1 missing). ;-)
14:22:08 <rdieter> well, anyway, doesn't matter now.
14:22:10 <Kevin_Kofler> FWIW, now we also have ltinkl agreeing, so that's +4.
14:22:37 <Kevin_Kofler> Users are being plagued by those annoying dialogs and have been complaining about it and we're sitting on the fix. :-(
14:22:59 <Kevin_Kofler> FWIW, I'd have queued the update directly to stable right upon making it.
14:23:29 <rdieter> I didn't feel comfortable doing that before I had 4 +1's, that's all
14:23:50 <rdieter> ok, so, Kevin_Kofler's proposing we fast-track this, anyone like/dislike that?
14:24:18 * thomasj_ likes it to fix the nepomuk anoying
14:24:36 <Kevin_Kofler> I guess at this point it's not going to matter all that much.
14:24:57 <Kevin_Kofler> We can let it go through testing and hit push to stable right after the testing push.
14:25:32 <jreznik> for this issue I'm for fast track - hopefully it should be safe
14:25:52 <ltinkl> +1, fast
14:26:24 <SMParrish> +1 no harm pushing it out
14:27:03 <than> than: it's fine with me
14:27:13 <rdieter> alright, the people have spoken, will do. (I was torn +0)
14:27:45 <rdieter> #agreed will queue kde-settings update to enable nepomuk for stable
14:28:10 <rdieter> #topic default cursor theme, https://bugzilla.redhat.com/show_bug.cgi?id=571039
14:28:42 <rdieter> I'd tend to go for consistency here, and ask libXcursor to just use dmz-aa everywhere
14:29:03 <Kevin_Kofler> I think the GNOME folks want plain dmz, not dmz-aa.
14:29:35 <jreznik> plain dmz theme icons are a little bigger
14:30:01 <Kevin_Kofler> FWIW, wouldn't the best solution be to remove that "default" hack from libXcursor entirely?
14:30:03 <jreznik> but still usable, oxygen is no way
14:30:05 <ltinkl> is there any preview, how they look like?
14:30:15 <jreznik> ltinkl: there's link
14:30:21 <Kevin_Kofler> GNOME doesn't use it anymore, and KDE only uses it because we set it in kde-settings.
14:30:27 <Kevin_Kofler> We could set an actual theme directly there.
14:30:28 <rdieter> http://jimmac.musichall.cz/themes.php?skin=7
14:30:29 <jreznik> ltinkl: http://jimmac.musichall.cz/themes.php?skin=7
14:30:41 <rdieter> jinx!
14:30:49 <jreznik> Kevin_Kofler: yes
14:30:57 <Kevin_Kofler> The solution in libXcursor is poor because it's missing a Requires, but adding that Requires would make the library depend on a particular theme for no good reason.
14:31:17 <thomasj_> dmz-aa looks nice.
14:31:21 <rdieter> Kevin_Kofler: no good reason, other than to make the default/expected theme work?
14:31:24 <ltinkl> I prefer plain dmz
14:31:49 <SMParrish> I prefer dmz-aa
14:31:54 <rdieter> Kevin_Kofler: of course, that could be made soft via just installing it via comps
14:31:57 <Kevin_Kofler> What's wrong with Bluecurve?
14:32:29 <than> rdieter: will dmz be used in gnome?
14:32:30 <rdieter> nothing's wrong with it per-se.
14:32:36 <rdieter> than: looks that way
14:32:37 <jreznik> than: probably yes
14:33:04 <jreznik> Kevin_Kofler: dmz is little more consistent... nothing wrong with bluecurve...
14:33:06 <than> i will say we should use dmz too
14:33:23 <than> jreznik: +1
14:33:50 <rdieter> bluecurve is a bit smaller than dmz, if that matters any
14:34:07 <ltinkl> I wouldn't say we should, I also like oxygen
14:34:09 <thomasj_> dmz looks old. But hey..
14:34:12 <jreznik> rdieter: yes, it's that's why I visually prefer dmz-aa
14:34:12 <nucleo> now even if set dmz-aa in systemsettings there is in kdm old KDE2 cursor theme
14:34:28 <Kevin_Kofler> I'd have an easier time getting used to dmz-aa, it looks more like Bluecurve, dmz is white, so completely different.
14:34:31 <rdieter> jreznik: I was talking about pkg size, but that's true too. :)
14:34:34 <jreznik> ltinkl: oxygen too gamish :) for starcraft maybe
14:34:42 <Kevin_Kofler> But most likely I'll be switching to Bluecurve manually anyway. :-)
14:34:44 <jreznik> rdieter: ah ;-)
14:34:50 <Kevin_Kofler> So don't bother designing for me. ^^
14:35:08 <jreznik> Kevin_Kofler: yes, dmz-aa is more bluecurve like
14:35:11 <rdieter> nucleo: systemsettings is per-user, but fixing this globally will make kdm work too
14:35:38 <jreznik> what I liked on bluecurve it was nice set of black and white cursors... not so consistent but better usability
14:35:40 <nucleo> rdieter: so, it will be fixed globally?
14:35:53 <rdieter> nucleo: yes
14:36:15 <Kevin_Kofler> Interestingly, in the Bluecurve cursor theme, the default pointer looks close to dmz-aa, the pointed index looks close to dmz.
14:37:07 <Kevin_Kofler> The bluecurve-cursor-theme is not all black or all white, but mixed.
14:37:45 <rdieter> ok, so for now, any objections if I comment in the aforementioned bug, to work towards making this consitent distro wide, and commit to using dmz (for now)?
14:37:58 <nucleo> like white cursor on links
14:38:09 * Kevin_Kofler still thinks Bluecurve is better. :-)
14:38:17 <ltinkl> rdieter: go
14:38:22 <SMParrish> rdieter: no objections here
14:38:33 <Kevin_Kofler> Why do we need to change to something different, just because it's not Bluecurve?
14:38:36 <thomasj_> It needs to be fixed, so better dmz than nothing
14:38:55 <Kevin_Kofler> thomasj_: IMHO, "nothing" is the best option for libXcursor.
14:39:01 <thomasj_> heh
14:39:04 <Kevin_Kofler> We should just set the theme to an actual theme name in kde-settings.
14:39:08 <Kevin_Kofler> Not "default".
14:39:41 <Kevin_Kofler> That "default" theme was there because old versions of GNOME needed it.
14:39:51 <Kevin_Kofler> And we set theme=default because it was there, I guess.
14:39:55 <rdieter> ok, let's put it another way, what's the point of even having a 'default' if it's not used anywhere?
14:40:52 <jreznik> nucleo: me too... that's my complain... I'd like to have dmz + dmz-aa together
14:40:54 <Kevin_Kofler> That "default" hack also leads to having the default theme listed twice in System Settings, once as "default" and once under its actual name.
14:41:08 <rdieter> may as well just get rid of it?
14:41:35 <rdieter> Kevin_Kofler: I don't see it listed twice ?
14:41:47 <rdieter> in icon themes or cursor theme?
14:42:15 * rdieter looked in both, no dups
14:42:16 <Kevin_Kofler> I guess KDE has added a blacklist for "default" to work around this.
14:42:22 <Kevin_Kofler> It used to be listed twice in the past.
14:42:26 <rdieter> ok
14:42:37 <Kevin_Kofler> So that particular issue seems not to be there.
14:43:03 <jreznik> nucleo: maybe we can ask for dmz remix - dmz for main cursor and dmz-aa for links etc...
14:43:04 <Kevin_Kofler> Hmmm, wait, I think it's actually GNOME's tools which love listing it twice because they don't understand "default" anymore. But that's not our problem. :-p
14:43:19 <rdieter> let's move on, looks like we've got semi-agreement here.
14:43:26 <rdieter> #topic roadmap/timeline to removing hal dependencies from kde?
14:43:29 <rdieter> ltinkl: ?
14:43:38 <Kevin_Kofler> I haven't fired up gnome-control-center for a long time now, as I don't run gnome-settings-daemon within KDE anymore (and KDE is all I use).
14:43:41 <rdieter> Some background:  In particular, mjg59 is suggesting removing storage support in hal to save huge amounts of power...
14:43:43 <jreznik> rdieter: what's semiagreement? :D stay with bluecurve?
14:43:50 <ltinkl> I wouldn't be optimistic about removing HAL
14:43:57 <ltinkl> I looked at the current state of udisks... it's simply not sufficient for Solid needs
14:44:00 <rdieter> jreznik: most folks ack'd my idea to use dmz already
14:44:18 <Kevin_Kofler> ltinkl: The limitations are a "feature", it seems. :-(
14:44:24 <jreznik> rdieter: so can I reply to Matthias we'd like to use it too?
14:44:26 <Kevin_Kofler> They decided to save power by simply removing all polling.
14:44:29 <nucleo> jreznik: thet that remix will replace dmz or dmz-aa or all of them will be installed?
14:44:39 <Kevin_Kofler> So goodbye to handling the CD player's eject key in software.
14:44:48 <Kevin_Kofler> Also goodbye to autodetecting inserted floppies.
14:44:48 <ltinkl> it doesn't provide features as read/write speeds for CD/DVD burners, type of media in CD/DVD readers
14:44:50 <rdieter> ltinkl: As I suggested yesterday, let's come up with a laundry-list of missing features that kde/solid needs
14:44:55 <ltinkl> lots of stuff would break in KDE
14:45:06 <Kevin_Kofler> (Floppy drives don't support autorun in hardware.)
14:45:15 <rdieter> stuff it in the wiki somewhere, and list those as blockers for hal removal.
14:45:27 <ltinkl> ejecting disks wouldn't work from the "Recently mounted" applet etc.
14:45:33 <rdieter> so we can point to that when the inevitable questions about deprecating hal come up again
14:45:37 <jreznik> Kevin_Kofler: list sounds good for me - to have something to say stop - do not remove hal w/o replacement
14:45:57 <Kevin_Kofler> jreznik: The thing is, they won't see those as arguments.
14:45:58 <rdieter> hal is not going to be removed
14:46:04 <Kevin_Kofler> Because they say polling just has to go away.
14:46:05 <rdieter> no one is suggesting that... yet
14:46:09 <ltinkl> ok if I collect a list of missing funtionality in terms what Solid needs (somewhere in wiki)?
14:46:10 <than> Kevin_Kofler: it's good arguments
14:46:16 <rdieter> ltinkl: yes, please.
14:46:30 <ltinkl> ok
14:46:30 <Kevin_Kofler> rdieter: But storage functionality is essential and they want to remove it.
14:46:42 <than> ltinkl: could you please create a list?
14:46:43 <jreznik> ltinkl: you're the one who knows it best ;-)
14:46:44 <rdieter> Kevin_Kofler: they won't if we still need it,that's the point
14:46:44 <Kevin_Kofler> They're also looking into making it enabled only under KDE somehow, not sure what that'll mean.
14:47:10 * thomasj_ has to leave.. Doctors appointment..
14:47:11 <Kevin_Kofler> It might lead to KDE apps in GNOME and/or added to the GNOME spin being badly broken.
14:47:12 <rdieter> Kevin_Kofler: I'm not sure either
14:47:25 <rdieter> thomasj_: take care
14:47:30 <thomasj_> thanks
14:47:34 <ltinkl> there are imho only 2 solutions, implement the missing functionality in udisks ourselves (unlikely), or maintain HAL
14:47:49 <rdieter> ltinkl: likely some combination of both, sooner or later
14:48:13 <Kevin_Kofler> rdieter: I'm not so positive, given how they've arbitrarily removed stuff under us in the past. :-/
14:48:17 <Kevin_Kofler> We may have to fight for it.
14:48:23 <ltinkl> I don't think udisks developers will let us implement stuff like polling if they are against it
14:48:36 <Kevin_Kofler> They're already refusing to support power management governor switching.
14:48:46 <jreznik> ltinkl: implement it directly in solid next to udisk?
14:48:48 <ltinkl> yup, the list is quite _long_
14:48:54 <rdieter> Kevin_Kofler: look, they asked us, and we're providing feedback to what we need.  that's all well and good, and nothing to complain about (yet).
14:48:57 <jreznik> reimplement all in solid?
14:49:03 <jreznik> and do not use udisk at all
14:49:08 <ltinkl> the problem is that Solid doesn't support "multi backend" approach
14:49:16 <ltinkl> you have to select exactly one, at compilation time
14:49:19 <Kevin_Kofler> ltinkl: That's planned for 4.5 or 4.6.
14:49:31 <Kevin_Kofler> And u* backends are also being worked on as part of that.
14:49:36 <ltinkl> Kevin_Kofler: yup I noticed some plans for it, 4.5 probably
14:49:41 <Kevin_Kofler> I think we're rushing things by trying to shoehorn that stuff into 4.4.
14:49:49 <jreznik> ltinkl: you can implement unimplemented stuff in udisk backend... it's hacky but...
14:49:56 <ltinkl> Kevin_Kofler: indeed, I don't think we have to rush this in
14:50:20 <jreznik> ltinkl, Kevin_Kofler: we still should be more involved in upstream development here
14:50:26 <Kevin_Kofler> We could have a kded4 module doing polling, but the problem is, udisks is also going to change things around to support non-polling which we may not want.
14:50:27 <ltinkl> imho it's more important to point out what we need to be on par with HAL backend
14:50:54 <Kevin_Kofler> E.g. they just want to let the CD player's eject key eject stuff directly (i.e. no longer lock it) instead of unmounting cleanly.
14:50:59 <rdieter> ltinkl: indeed, that's the primary exercize here
14:51:21 <Kevin_Kofler> So we'd also have to relock it if udisks unlocks it, not just install a kded4 module to handle polling.
14:51:34 <Kevin_Kofler> Plus, the polling probably needs a privileged part, which kded4 is not designed for.
14:51:36 <rdieter> udisks folks need also to be aware of kde's needs, and if they expect kde to use it, they need to compromise a bit too
14:51:48 <Kevin_Kofler> rdieter: I think polling is not debatable.
14:52:02 <Kevin_Kofler> They consider it a waste of power and think desktops need to live without it.
14:52:28 <rdieter> right, if we/kde/solid consider that a deal-breaker, then we need to communicate that
14:52:45 <jreznik> rdieter: upstream should be more involved
14:52:59 <jreznik> it's problem with kde upstream - really very reactive and not proactive
14:53:00 <rdieter> *foo* should be more involved.
14:53:50 <Kevin_Kofler> Another issue is that stuff constantly changes, often in cycles.
14:53:56 <rdieter> ltinkl: any other hal-related solid dependencies that we should be worrying about?
14:54:10 <Kevin_Kofler> E.g. X input settings were in xorg.conf, then they moved to HAL, and now they moved back to xorg.conf(.d).
14:54:45 <Kevin_Kofler> Sure, progress is made, but the place stuff is implemented in often rotates in cycles.
14:54:46 <ltinkl> rdieter: don't think so, other than what Kevin mentioned, udisks is not really stable API and ABI wise
14:55:13 <rdieter> ltinkl: ok, document that too, while making your list.
14:55:54 <Kevin_Kofler> Some new cool thing like HAL is introduced, everything moves to getting handled by HAL, and suddenly HAL is deprecated and everything moves away from HAL.
14:56:01 <Kevin_Kofler> And often back to where it originally was.
14:56:25 <rdieter> #action ltinkl to document a list of udisk missing features, that block our removal of hal dependencies from kde/solid
14:56:50 <rdieter> Kevin_Kofler: indeed
14:57:25 <rdieter> #topic open floor
14:57:35 <rdieter> about out of time for today, any last thoughts?
14:57:35 <Kevin_Kofler> For example, handling device permissions for the local ("console") user is a PITA, the way to do it has changed at least 5 times.
14:57:46 <Kevin_Kofler> I've been through all of them with my CalcForge packages.
14:59:40 <rdieter> ltinkl: I know you're probably very busy already, but would you be able/interested in helping comaintain hal in fedora?
15:00:15 <ltinkl> rdieter: I can try :) no idea how much work it is
15:00:19 <rdieter> I've offered the help already, and I think it would be wise to have one of our own helping more closely there
15:00:37 <rdieter> ltinkl: at first, I'd assume very little work.
15:01:01 <ltinkl> rdieter: from what I've heard, there will be no more development in HAL, only 1 or 2 maintenance releases
15:01:02 <rdieter> but I'd like to have someone at least helping keep an eye on things there, to help with kde-specific features, issues there
15:01:16 <rdieter> that's fine.
15:01:32 <Kevin_Kofler> Maybe someone should actually fork HAL?
15:01:47 <Kevin_Kofler> Or at least add patches like the LVM patch somebody supposedly wrote?
15:01:56 <rdieter> hal fork = DeviceKit, PowerKit, *foo*Kit
15:02:11 <Kevin_Kofler> They're not forks, they're rewrites.
15:02:39 <jreznik> Kevin_Kofler: rewrites that was rewrited because old one sucked and new ones sucks much more :(
15:02:40 <rdieter> no need to fork, if you want stuff to happen, work to get it upstream.
15:02:58 <rdieter> unless upstream rejects it I guess...
15:03:05 <rdieter> anyway, out of time now.  thanks everyone.
15:03:07 <jreznik> or write solid backend from scratch - no udisks, hal
15:03:13 <rdieter> #endmeeting