From: Marcel Holtmann <marcel@holtmann.org>
To: KeiHachi <keihachi@swissinfo.org>
Cc: BlueZ Mailing List <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] Questions about BlueZ in commercial use
Date: Sun, 27 Jun 2004 20:29:30 +0200 [thread overview]
Message-ID: <1088360970.3774.39.camel@pegasus> (raw)
In-Reply-To: <001101c45c55$7803b160$0364a8c0@haruo>
Hi Keihachi,
I think Nicholas answered most of your questions quite well, but I must
comment on this part.
> For example, Affix provides us these two versions software,
> the testing version and the stable version.
> http://affix.sourceforge.net/#download
>
> I suppose such version control or management like Affix.
What you really wan't doesn't exists in the real world. Most Open Source
projects differ between stable and unstable/testing trees, but how do
you define the difference between them? The general problem is that they
think their API is not sufficient and so they are going to redesign it
and use the next major version for it. We will do actually the same, but
as long as we don't break any backward compatible there is no need to do
this.
If you wanna choose a Bluetooth stack that has a clear stable and
testing version then go with the Affix and use it. I am not going to
provide such version control, because I doesn't work out for us. What I
can give is a clear statement about what protocols (or profiles) are
stable within the complete BlueZ stack. So you should know what you need
and I can give you a more detailed answer about it.
> If a new profile is testing or has been released immediately after the development,
> probably some bugs are still included.
I don't take this point for sure, because even software declared as
stable has bugs ;)
> So we think if BlueZ is used for the commercial use, the stable version is necessary,
> because a commercial product is required to be a high quality.
Bugs are bugs. Even if I declare a BlueZ version as stable, I can't
assure that I don't overlooked something. This is the human part of
software engineering. Lets talk about details and not esoteric needs.
Regards
Marcel
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2004-06-27 18:29 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-27 9:47 [Bluez-devel] Questions about BlueZ in commercial use KeiHachi
2004-06-27 12:52 ` Nicholas A. Preyss
2004-06-27 14:45 ` KeiHachi
2004-06-27 17:13 ` Nicholas A. Preyss
2004-06-28 16:30 ` KeiHachi
2004-06-28 17:22 ` Marcel Holtmann
2004-06-27 18:29 ` Marcel Holtmann [this message]
2004-06-28 16:33 ` KeiHachi
2004-06-28 17:45 ` Marcel Holtmann
2004-06-28 14:39 ` Ademar de Souza Reis Jr.
2004-06-28 14:48 ` Marcel Holtmann
2004-06-28 15:19 ` Ademar de Souza Reis Jr.
2004-06-28 15:38 ` Marcel Holtmann
2004-06-28 15:59 ` Stephen Crane
2004-06-28 17:06 ` Ademar de Souza Reis Jr.
2004-06-28 17:15 ` Marcel Holtmann
2004-06-27 18:09 ` Marcel Holtmann
2004-06-27 19:10 ` Nicholas A. Preyss
2004-06-27 19:09 ` Marcel Holtmann
2004-06-27 20:34 ` Nicholas A. Preyss
2004-06-27 20:49 ` Marcel Holtmann
2004-06-27 21:42 ` Nicholas A. Preyss
2004-06-28 7:37 ` Marcel Holtmann
2004-06-28 16:28 ` KeiHachi
2004-06-28 17:13 ` Marcel Holtmann
2004-06-29 17:08 ` KeiHachi
2004-06-29 17:41 ` Marcel Holtmann
2004-06-30 16:22 ` KeiHachi
2004-06-30 18:11 ` Marcel Holtmann
2004-07-04 8:57 ` KeiHachi
2004-07-04 11:38 ` Marcel Holtmann
2004-07-04 13:19 ` Peter Favrholdt
2004-07-04 13:47 ` Marcel Holtmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1088360970.3774.39.camel@pegasus \
--to=marcel@holtmann.org \
--cc=bluez-devel@lists.sourceforge.net \
--cc=keihachi@swissinfo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox