[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