public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
* [PROPOSAL bluetoothd/obexd] doc/features.txt and doc/TODO
@ 2012-05-24 19:44 Lucas De Marchi
  2012-05-24 20:12 ` Gustavo Padovan
  0 siblings, 1 reply; 2+ messages in thread
From: Lucas De Marchi @ 2012-05-24 19:44 UTC (permalink / raw)
  To: Marcel Holtmann, Denis Kenzior, Johan Hedberg,
	Luiz Augusto von Dentz
  Cc: BlueZ development

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PROPOSAL bluetoothd/obexd] doc/features.txt and doc/TODO
  2012-05-24 19:44 [PROPOSAL bluetoothd/obexd] doc/features.txt and doc/TODO Lucas De Marchi
@ 2012-05-24 20:12 ` Gustavo Padovan
  0 siblings, 0 replies; 2+ messages in thread
From: Gustavo Padovan @ 2012-05-24 20:12 UTC (permalink / raw)
  To: Lucas De Marchi
  Cc: Marcel Holtmann, Denis Kenzior, Johan Hedberg,
	Luiz Augusto von Dentz, BlueZ development

* Lucas De Marchi <lucas.demarchi@profusion.mobi> [2012-05-24 16:44:47 -0300]:

> 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.

We actually have a TODO file in BlueZ, but it seems out of date. I think it
was started it during the initial phase of the LE development, but it was
abandoned at some point.

doc/features.txt would be interesting as well.

	Gustavo

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2012-05-24 20:12 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-05-24 19:44 [PROPOSAL bluetoothd/obexd] doc/features.txt and doc/TODO Lucas De Marchi
2012-05-24 20:12 ` Gustavo Padovan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox