Hi Brian, In our plan, we will firstly have a wide survey about the project to know about the exact requirement. I hope that we will receive various feedback and comments. Meanwhile, it is also a chance by which we have a dialog with other teams. According to the feedback, we will directly talk with some teams to further exchange ideas. All of the work will be done prior to the further design.
Thanks for your advice again. Regards, Strony Brian Cameron : > Strony: > > >> You shared good thoughts, thanks. The current status is, folks from USB, >> HAL and JDS teams are working together on the project. Experts from >> userland to kernel are included. Sure, more people from different teams >> will be involved. We also had quite a few discussion with Vijay who >> proposed the similar project about two months ago in order to work >> together to move the project forward. As regards our proposed different >> technical solution, we will have a deep discussion in the following. It >> is a good thing to see different ideas and I believe the ideas will make >> the project better. >> > > Let me be clear. I do think competition is good, and I do think it is > good to offer users more choice. I am in no way opposed to this > project. Nor am I aware of any specific problems. > > It just sounded to me that you hadn't directly contacted the other teams > working in this space yet. I highly recommend that you do so early in > your project. As I said, this will help you to identify additional > teams you should be working with, help you to better understand the > requirements (since the other teams may be aware of requirements that > you are not and vice versa), and might lead to further opportunities for > more effective collaboration. It also reduces risk, since if there are > any issues it is good to discover them early. It is usually easier to > collaborate when dialog happens early rather than late. > > >> It is an opensource project and will be developed in community. The more >> people involved, the better. We are in the beginning stage now. The >> first step is just to kick off the project and have a project page for >> people to share ideas. In the following, we will collect the necessary >> feedback and then have the detailed design according to the exact >> requirement. Let's start it and enjoy. >> > > Brian > > > >>>> At fact, we are the USB device driver team. We are working on both USB >>>> and HAL fields now. Last year, Simon (JDS team member) and I worked out >>>> a simple prototype based on Gnome-device-manager by which users can >>>> enable/disable the USB devices. The screenshot about the GUI demo is >>>> attached. If necessary, we will contact with other kernel teams to move >>>> the project forward. >>>> >>>> >>> It sounds like we recently discovered that there is a separate project >>> working on similar technology. It would be a good idea to touch base >>> with them, and talk through these issues to make sure we are on the >>> same page. >>> >>> Ideally we should have some answers to the following sorts of questions: >>> >>> - Do the two projects overlap or do they provide unique functionality? >>> In what areas do they provide unique functionality? Are there >>> opportunities for the two projects to further converge? >>> >>> - What kernel groups does the other Device Management project have >>> a relationship with? Is it the same groups as the ones you are >>> working with? If not, does this mean your group should develop >>> a closer relationship with these other kernel groups? >>> >>> - It would be handy to have a better understanding of the pros and >>> cons of the two applications and to have a more clear story about >>> why having both adds value. >>> >>> You say above that you will only contact the other kernel groups if >>> necessary to move the project forward. How do you know if it is >>> necessary without first contacting them? I would think we would >>> need to learn about the requirements of the other Device Management >>> project to understand how this project fits in. To do this, isn't >>> it necessary to develop a dialog with them? >>> >>> There have been some situations within Sun where projects have >>> gotten canceled because there was a competing project that did the >>> same thing. You reduce the risk that your project will eventually >>> get canceled if you make sure that you start dialogs early when >>> you discover there are potentially competing projects being worked >>> on by other teams within Sun. >>> >>> Brian >>> >>> >>> >>> >>>> simon.zheng at sun.com : >>>> >>>> >>>>> On Thu, 2008-03-27 at 11:22 -0500, Brian Cameron wrote: >>>>> >>>>> >>>>> >>>>>> Irene: >>>>>> >>>>>> Obviously a project which is intended to manage devices needs to >>>>>> interact with the kernel, where the devices actually live. Although >>>>>> the reasons you give below are good, you don't give any indication >>>>>> that there has been any dialog with the appropriate kernel teams to >>>>>> make sure this project is in-line with their plans, that they intend >>>>>> to support the needed HAL interfaces, etc. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Opensolaris is an open community, there's no policy that projects with >>>>>>> similar functionality should not co-exist in the community. >>>>>>> I am not familiar about the other device manager project. I was told >>>>>>> that both the structure and the GUI are different. If this is the case >>>>>>> I'd say that it won't hurt to have both these projects on >>>>>>> opensolaris. >>>>>>> >>>>>>> >>>>>> Has there been any dialog with the appropriate kernel groups to >>>>>> ensure that this project will be an ongoing success? There has been >>>>>> mention of an existing Device Manager project. Does this other project >>>>>> already have the buy-in of the kernel groups? What is their opinion >>>>>> of having multiple projects with similar functionality? Are they >>>>>> willing to support needed interfaces interfaces for both Device Manager >>>>>> projects? What are the issues, if any, in this space? >>>>>> >>>>>> >>>>>> >>>>> As I known, Strony's proposal is based on X86 driver development team >>>>> requirement, especially hotplug devices really desire it. >>>>> Enable/disable hotplug device is very useful I think. So I'm sure USB >>>>> guys would like to support. Currently HAL + gnome-volume-manager can >>>>> already automatically mount USB storage device. But it doesn't seem to >>>>> deal with other kinds of USB devices. >>>>> >>>>> For non-hotplug devices, perhaps we need more feedback. >>>>> >>>>> With regard to gnome-device-manager, it has a bit of history. Before HAL >>>>> v0.5.9, a subordinate GUI tool "hal-device-manager" written in Python is >>>>> widely distributed on Linux and FreeBSD. In the latest HAL 0.5.10, >>>>> hal-device-manager is rewritten in C and deliever a separte project >>>>> called gnome-device-manager. >>>>> >>>>> Anyway, personally I like such a gnome-device-manager to deal with >>>>> hotplug devices, e.g. allowing me to manually unable/disable usb device >>>>> from system tray, or notification can be popep up in system tray when I >>>>> plug USB device. >>>>> >>>>> -Simon >>>>> >>>>> _______________________________________________ >>>>> desktop-discuss mailing list >>>>> desktop-discuss at opensolaris.org >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------ >>>> >>>> This body part will be downloaded on demand. >>>> >>>> >>> _______________________________________________ >>> desktop-discuss mailing list >>> desktop-discuss at opensolaris.org >>> >>> >> _______________________________________________ >> desktop-discuss mailing list >> desktop-discuss at opensolaris.org >> > > _______________________________________________ > desktop-discuss mailing list > desktop-discuss at opensolaris.org >
