From Fedora Project Wiki
(→‎QA comments about Scope: add sig for comments, respond to mclasen)
 
(5 intermediate revisions by 4 users not shown)
Line 1: Line 1:
= Questions =
= Questions =


Will anything using hal now need to be ported by F10, or will that keep working?  
# 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
In particular I am wondering about thunar-volman (the Xfce Thunar plugin that handles removable devices).  
#*"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
Is the any docs or API info that I could point upstream thunar-volman at?  
# Would we really roll back this feature if the KDE side of things isn't done in time? - JesseKeating
- kevin
#*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 that's 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
#*Careful, not all the packages using HAL are linked to one of its libraries, for example Solid uses it through Qt 4's D-Bus binding only, so the list may be incomplete. --[[User:Kkofler|Kkofler]] 21:25, 11 July 2008 (UTC)
# 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


"anything using hal" - no. See scope: things using hal for disk information will
= FESCo 2008-07-10 =
have to be ported, such as gvfs, Solid and thunar-volman. I've added a link to the api docs. - Matthias
* This feature is not ready for acceptance the questions from FESCo are above
 
* Please move feature page to Category:ProposedFedora10 when your page is ready for re-review.
 
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
== QA comments about Scope ==


The scope section has a (partial) list of changes that are expected in F11, but most of those items are either incomplete or not testable:


A porting guide for Fedora packagers would be extremely helpful.
# Bug fixes in "a number of components, such as kernel, udev, mdadm, lvm."
#* Is this a complete list? Could you complete it, perhaps a with tracker bug so we can follow progress?
# "At a very minimum hal needs to talk to DeviceKit-disks about locking and mounting/unmounting."
#* Is there a bug id for this, or can you write a small script so we can check to see if HAL is doing this?
# "Core components that we want to have ported for F11 include gvfs, gnome-mount, nautilus and gnome-power-manager."
#* Is this the complete list?
#* Which ones have been ported and which haven't? I see that gnome-power-manager is using DeviceKit but I'm unsure of the status of the rest.
#* How can a normal user check to see if these components are using HAL or DeviceKit?
# "we don't expect to port most of these for F11."
#* Are there any you *do* plan to port? If so, can you list them? If not, can you replace "most" with "any"?


I agree that a porting document would be useful in general, not just for Fedora packagers. - Matthias
Feel free to contact the [[QA]] team if you want help or further clarification.


--[[User:Wwoods|WillWoods]] 22:53, 22 January 2009 (UTC)


How about a hal compatibility layer?
Will, I don't think there is quite as much unclarity in that section. There is a short list of components that need to be ported to make DeviceKit compelling. That is the first list. And there is a long list of _all_ components depending on hal (that is the second list). As you will notice, there is overlap. Which sort of answers your last question. We plan to port the modules on the first list, which is a small subset of the second list. Some other components may move to depend on DeviceKit/udev on their own, e.g. NetworkManager. For information on what has and hasn't ported, look up to the status section.


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
-- [[:User:Mclasen|Mclasen]] 20:05, 22 January 2009 (UTC)
should not be hard. We have the source. - Matthias


= FESCo 2008-07-10 =
Okay, I guess I was just confused about whether those lists were complete, because the language implies that some stuff might be missing. I'm going to modify the language in the Scope section to be less ambiguous - e.g. "the core components we plan to port for F11 are X, Y, and Z..." Please correct it if I get anything wrong. Thanks.
* 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
--[[User:Wwoods|WillWoods]] 22:53, 22 January 2009 (UTC)
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

Latest revision as of 22:53, 22 January 2009

Questions

  1. 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
  2. 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 that's for David to say in detail. - Matthias
  3. What about anaconda integration?
    • anaconda integration will happen when the anaconda team decides that it is the right thing to do. - Matthias
  4. 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
    • Careful, not all the packages using HAL are linked to one of its libraries, for example Solid uses it through Qt 4's D-Bus binding only, so the list may be incomplete. --Kkofler 21:25, 11 July 2008 (UTC)
  5. 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
  6. 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 questions from FESCo are above
  • Please move feature page to Category:ProposedFedora10 when your page is ready for re-review.

QA comments about Scope

The scope section has a (partial) list of changes that are expected in F11, but most of those items are either incomplete or not testable:

  1. Bug fixes in "a number of components, such as kernel, udev, mdadm, lvm."
    • Is this a complete list? Could you complete it, perhaps a with tracker bug so we can follow progress?
  2. "At a very minimum hal needs to talk to DeviceKit-disks about locking and mounting/unmounting."
    • Is there a bug id for this, or can you write a small script so we can check to see if HAL is doing this?
  3. "Core components that we want to have ported for F11 include gvfs, gnome-mount, nautilus and gnome-power-manager."
    • Is this the complete list?
    • Which ones have been ported and which haven't? I see that gnome-power-manager is using DeviceKit but I'm unsure of the status of the rest.
    • How can a normal user check to see if these components are using HAL or DeviceKit?
  4. "we don't expect to port most of these for F11."
    • Are there any you *do* plan to port? If so, can you list them? If not, can you replace "most" with "any"?

Feel free to contact the QA team if you want help or further clarification.

--WillWoods 22:53, 22 January 2009 (UTC)

Will, I don't think there is quite as much unclarity in that section. There is a short list of components that need to be ported to make DeviceKit compelling. That is the first list. And there is a long list of _all_ components depending on hal (that is the second list). As you will notice, there is overlap. Which sort of answers your last question. We plan to port the modules on the first list, which is a small subset of the second list. Some other components may move to depend on DeviceKit/udev on their own, e.g. NetworkManager. For information on what has and hasn't ported, look up to the status section.

-- Mclasen 20:05, 22 January 2009 (UTC)

Okay, I guess I was just confused about whether those lists were complete, because the language implies that some stuff might be missing. I'm going to modify the language in the Scope section to be less ambiguous - e.g. "the core components we plan to port for F11 are X, Y, and Z..." Please correct it if I get anything wrong. Thanks.

--WillWoods 22:53, 22 January 2009 (UTC)

Retrieved from "https://fedoraproject.org/w/index.php?title=Talk:Features/DeviceKit&oldid=73136"