[PROPOSAL bluetoothd/obexd] doc/features.txt and doc/TODO

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey,

Some times (mainly when I'm preparing presentations about BlueZ) I
have to dig the source code and commit log to check which version and
features of each protocol is supported in BlueZ. I think this is a
common pattern for other BlueZ developers as well. It matters even
more when we are proposing implementations of new features (and then
we realize it's already implemented) or when we are trying to cover a
use case that depends on a feature not done yet.

I propose to follow what oFono does, by maintaining a
doc/features.txt and a doc/TODO  (I don't think the
"Priority"/"Complexity" is very important in the latter but could be
done as well). I'd prefer each developer to fill in the file for
profiles he's used with, so the end result is more accurate than if we
had only 1 person to do it all. I can contribute an initial version
with the features I found the last time I did that.


What do you think?

Regards,
Lucas De Marchi
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux