[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