From Fedora Project Wiki

No edit summary
Line 38: Line 38:
= FESCo 2008-07-10 =
= FESCo 2008-07-10 =
* This feature is not ready for acceptance the IRC log follows
* This feature is not ready for acceptance the IRC log follows
* Please move feature page to Category:ProposedFedora10 when your page is ready for re-review.
13:28 -!- bpepple changed the topic of #fedora-meeting to: FESCo-Meeting -- Features -- https://fedoraproject.org/wiki/Features/DeviceKit - poelcat
13:28 -!- bpepple changed the topic of #fedora-meeting to: FESCo-Meeting -- Features -- https://fedoraproject.org/wiki/Features/DeviceKit - poelcat
13:29 < bpepple> This looks pretty cool.
13:29 < bpepple> This looks pretty cool.

Revision as of 23:33, 10 July 2008

Questions

Will anything using hal now need to be ported by F10, or will that keep working? In particular I am wondering about thunar-volman (the Xfce Thunar plugin that handles removable devices). Is the any docs or API info that I could point upstream thunar-volman at? - kevin

"anything using hal" - no. See scope: things using hal for disk information will have to be ported, such as gvfs, Solid and thunar-volman. I've added a link to the api docs. - Matthias


Would we really roll back this feature if the KDE side of things isn't done in time? - JesseKeating

I don't think so. We'd probably look for a way to keep the hal disks part running next to DK-disks without stepping on each others toes, but thats for David to say in detail. - Matthias


What about anaconda integration?

anaconda integration will happen when the anaconda team decides that it is the right thing to do. - Matthias


What Fedora packages would be affected by this change?

See scope. We might need to do a more detailed analysis of the inverse hal dependencies. - Matthias


A porting guide for Fedora packagers would be extremely helpful.

I agree that a porting document would be useful in general, not just for Fedora packagers. - Matthias


How about a hal compatibility layer?

Compatibility layers are generally a bad idea when we can avoid them. From my understanding, the DK-disks api is very similar to the hal disk api, so porting should not be hard. We have the source. - Matthias

FESCo 2008-07-10

  • This feature is not ready for acceptance the IRC log follows
  • Please move feature page to Category:ProposedFedora10 when your page is ready for re-review.

13:28 -!- bpepple changed the topic of #fedora-meeting to: FESCo-Meeting -- Features -- https://fedoraproject.org/wiki/Features/DeviceKit - poelcat 13:29 < bpepple> This looks pretty cool. 13:29 < bpepple> +1 13:29 < f13> +1 from me 13:29 < f13> although I disagree that release notes aren't necessary 13:29 < f13> it might be necessary to make sure existing release notes don't have directions that would benefit from actually having DeviceKit to use 13:29 < tibbs> Yes, this looks neat. 13:29 < wwoods> Test plan needs a *lot* of fleshing out, but it's not in rawhide yet, so that's not critical 13:29 < notting> +1 13:30 < tibbs> I note that currently it's set up to block on the KDE stuff being ported. 13:30 < f13> tibbs: yeah, that's something to pay close attention to 13:30 * nirik wonders how if at all it will work under Xfce/others... 13:30 < spot> will this integrate with anaconda? 13:31 < f13> spot: there is talk of that yes 13:31 < dgilmore> its light on detail, but otherwise it looks ok 13:31 < spot> i would hate for it to look significantly different 13:31 < f13> <jeremy> fyi -- we might be "lucky" enough to get to switch our disk probing to use devicekit instead of hal for f10. davidz was typically cagey about what would remain and when things would land :-/ 13:31 < dgilmore> nirik: there is mention of KDE but thats it 13:31 < f13> Dependencies 13:31 < spot> f13: it would be nice to see anaconda integration as an item 13:31 < f13> Solid's (KDE's) disk management also needs to be ported to DeviceKit-disks. 13:31 < tibbs> I read through the mailing list thread and the explanations seem to make sense. 13:32 < jlaska> it notes it's a partial replacement for hal ... it would seem worthwhile identifying which pieces it's taking over (from a testing perspective) 13:32 < tibbs> But I wonder how much of our system links into the HAL stuff that we don't really know about. 13:33 < tibbs> nirik: Do you know the extent that xfce plays with hal? 13:33 < wwoods> jlaska: yeah, we'd want to expand the test plan to include other stuff that uses (used) HAL's disk support 13:33 < tibbs> "Components which depend directly on the disk functionality in hal, such as gvfs and Solid, have to be ported to DeviceKit-disks." 13:33 * jlaska runs rpm -q --whatrequires hal 13:33 < nirik> tibbs: thunar-volman uses it to find removables, etc. 13:33 < nirik> so there would need to be changes there probibly. 13:34 < tibbs> Then it may be worth getting clarification on that, and the porting of that added to the "Dependencies" section. 13:35 * f13 notes that these are all wonderful questions for the discussion tab 13:35 < notting> there's a certain point at which things are pushed to the upstream of said technologies 13:35 < nirik> sure, can add some to the discussion tab. 13:35 < bpepple> f13: agreed, we need to add them there. 13:35 < tibbs> Well, sure, but we're kind of in a meeting to vote on it now. 13:35 < spot> i'm not opposed to this feature, it sounds great... but given how intrusive it will be, i'd like to see a lot more details on porting other components 13:35 < notting> for example, if openssl changes api/abi , it's not necessarily up to the openssl maintainer to port everything 13:35 < spot> notting: no, but it sure is nice when they describe how to port. 13:36 < wwoods> details on porting, hints on finding things that will need updates 13:36 < jlaska> ... yeah, applications that must be changed to use DeviceKit by F10 13:36 < f13> pointers to documentation 13:37 < tibbs> I guess it would be at least nice to know if it's just the matter of calling different function names and listening for different dbus messages or whether there's a complete logic rewrite required. 13:38 < jlaska> maybe a DeviceKit-hal layer is used to map the old methods to the new? dunno if possible </crack> 13:38 < tibbs> So I think we're at three +1's at the moment. 13:38 < jlaska> I think we'd want some of these questions answered before we fully take it, no? 13:38 < spot> i'm not comfortable voting +1 without some of these items addressed 13:39 < tibbs> Can we provide a list of requests for additional info? What do you want to see? 13:39 < spot> details on anaconda integration 13:40 < spot> list of packages affected by the change 13:40 < f13> I'm really curious if they'd roll it back if the KDE part isn't done in time 13:40 < bpepple> spot: I'm fine with that. How about the people with questions they want answered add them to the discussion page. 13:40 < dgilmore> spot: agreed 13:40 < tibbs> "Please provide links to documentation and porting information"? 13:40 * nirik added a thunar-volman question to the discussion tab... 13:40 < f13> I added my question too 13:41 < spot> mine as well