Re: [Bluez-devel] Questions about BlueZ in commercial use

Nicholas A. Preyss
2004-06-27T21:42:33Z

On 0, Marcel Holtmann <marcel@holtmann.org> wrote:
> the current USB subsystem (as of 2.6.7) is not as bad as you think.
> Actually it is working very nice and even the hci_usb driver didn't
> crash anymore. Anyhow the problem is not USB. We made all of them by
> ourself :(

I think the problem is USB. It is too complicated for the least cost
market. So many manufacturers built chips or firmware for USB devices
which are not spec compliant. Additionaly there are so many bad
programmed driver.
I think this is a design failure, even if it only appears as bad driver
implementations.

> > The debian project shows that if you really want such high quality
> > standards for use in embedded devices e.g. it is possible to keep your
> > own stable branch. I think it is very easy with a good Changelog.
>
> I really like the Debian way of forking a stable version and only doing
> security or bugfixes. The problem is that this needs a lot of man power
> and costs a lot of time. I know what I am talking about, because I did
> all the 2.4 kernel backports of the Bluetooth subsystem.

A company would need to do this for the version they use in production
systems only. So it should be possible.

> If we got a number of companies that help sponsoring the BlueZ itself
> and its official qualification I can think of such a fork. At that point
> it makes sense to me and is worth the extra work.

I didn't thought of you maintaining such a stable fork. But like in the
debian project, the developers who need this high quality standard, care
for the branch themselves. Then you need to assure only, that all fixes you
apply are documented and published, even if you fix them with a new feature
that doesn't go into the stable tree.

nicholas