[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] New bug and bugs
|
Hi Scott,
thanks for everything. I've posted my use case to the osgi-dev
mailinglist, if you are interested. I'm student, so this is scientific
work and I won't have a problem if it does not run perfect, it's mainly
theory and architecture I'm addicted to.
I will try to find my way on my own first and ask then. I'll also try to
file bugs and would like to do some documentation, hope I can find the time!
Martin
P.S. It does work fine with ECF (jmdns, generic) at the moment, still
try to get the eventing distributed.
Am 06.12.2010 21:02, schrieb Scott Lewis:
Hi Martin,
On 12/4/2010 7:04 AM, Martin Petzold wrote:
Hi,
I've fired a new bug [1]. There are really several bugs with
different distribution providers on one machine. Is this way of
documenting them okay (as still student I'm new to this!)? There are
also still bugs with R-OSGi, also with two machines and also a wrong
configuration in one example. Shall I fire really every bug I find or
first mail to the mailinglist? Shall I attach eclipse
projects/working sets as examples to the bug or which form?
I suggest that generally you create a bug...and attach any code
examples that demonstrate the issue to the bug. Then, it's often a
good idea to also create a post to this list...if it's a general issue
(I understand that it may not be immediately obvious whether a given
issue is 'general' or not...but I would err on the side of more posts
to ecf-dev rather than less).
For me at the moment in my project ECF 3.4 is not stable and I do
have several problems! Hope I can help and get this all working...
I do too...and we'll do all we can to help.
One thing to realize...because the committers on ECF are mostly doing
this unpaid/on volunteer time, we are not able to provide a huge
amount of free support. We do as much as we can...hopefully without
causing ourselves personal harm...as all ECF committers are dedicated
and interested in having everyone successfully use ECF (remote
services as well as other things).
A corollary to the above is that if you have the means you should
consider either supporting ECF as a project (e.g. contribute fixes,
contribute new/desired components, contribute documentation,
contribute hw, people, or $$ resources), or supporting the individual
committers (e.g. hire them for consulting or development on your
project) so that they can help with your particular use cases. In
many cases, I've found that it's much more cost effective...as well as
fast...to ask/work with someone who designed/built the relevant
components (i.e. one of the ECF committers that implemented those
components) rather than to personally learn all the details of
something as sophisticated as a remoting/distribution infrastructure
(or shared editor, or real-time collaboration-enabled dev tooling, or
VOIP, or etc).
As I hope everyone realizes, there are lots of use cases for remote
services...and lots of details/subtlety WRT configuration,
documentation, API usage, failure handling, and how things can be done
(e.g. which ECF remote service providers to use...how to use them, how
to scale, etc). This is a good thing, as it means that OSGi remote
services (and ECF's implementation) can be used for lots of things,
but it also means that we as the implementers of the standard and
committers on ECF cannot anticipate everyone's use cases...and even if
we could/do anticipate them we can't possibly address all of them
instantaneously. Given current resources, we have to make choices
about what things to do, and what we cannot do. It would be nice to
not have to make so many of these choices, but we currently do not
have that luxury.
But we will provide support, bug fixes, new capabilities, support new
use cases, support additional standards, as much as possible. Just
realize that there are personal limits here...in available time,
number of active contributors, availability of people with sufficient
knowledge of relevant parts. We *are* interested in seeing everyone
use ECF successfully.
Scott
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=331836
Regards
Martin
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
--
Martin Petzold
Martinsfeld 14
D-50676 Köln
Deutschland
Telefon: +49 (0)221 / 2595961
Mobil: +49 (0)179 / 9220154
Blog: www.zetablog.de
