[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] New bug and bugs
|
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
