ekiga-list@gnome.org
[Top] [All Lists]

Re: [Ekiga-list] 473 Filtered destination

Subject: Re: [Ekiga-list] 473 Filtered destination
From: Palo S.
Date: 30 Dec 2008 15:06:30 +0100 CET


----- Originálna Správa -----
Od: yannick  
Komu: Ekiga mailing list  
Poslaná: 30.12.2008 12:40 
Predmet: Re: [Ekiga-list] 473 Filtered destination

> Le mardi 30 dĂŠcembre 2008 Ă  12:00 +0100, Palo S. a ĂŠcrit :
> > I have reproduced the same problem on yet another computer 
> > running Ubuntu with Ekiga 3.0 packaged by Yannick. So my 
> > suspicion on distribution specificity is wrong. I am even 
> > more wondering why nobody else complains about this...
> > weird.
> > 
> 
> This is quite an interesting question.
> 
> I must admit I\'ve seen myself the same issue you reported: my ekiga 3
> not being able to accurately display presence for my contacts in the
> long run.

Well, the issue that I reported causes more important
problem - it is not possible to reach the client after
some time (ie no incoming calls because server rejects them
although outcoming work just fine). And this is something 
I thought people would notice and report... However, wrong 
presence indication accompanies this issue so maybe you 
actually do suffer by the same problem? It is easy to see 
in the logfile: after some time there are no messages at 
all. Also, the client cannot be closed properly then.

> 
> Why I did not reported this? My packs are not latest stable version, I
> did not have something more accurate than just I can see it did not work
> all time. In short, I did not believe I had enough to track the bug down
> efficiently. And I also admit my commitment to this project is sometime

I also noticed more issues but did not report from the
same reasons. Presence indication not working correctly 
after some time was the first I noticed. Then there is 
video not transmitted when using theora codec in certain 
cases, h264 not initialized correctly in certain cases, 
occasional hang of Ekiga when releasing the call...
However these issues are clearly not that important and
not so reproducible as the one that I reported.

> weaker... Let\'s no fall in the mistake of being guilty, but when
> comparing to other similar projects backed by profit, it is quite
> depressing.

Yes, this is clearly a problem. However, I have been using 
Ekiga 2 for some 2 years for calls with relatives without any 
major problems and I can say that in my experience and for my 
purposes it worked significantly better than Skype. And
Ekiga 3 is close to fix the remaining smaller problems or
missing features I had with 2 (such as cpu getting to 100%
with video or missing presence indication). So the state
of Ekiga is clearly not that depressing. Given the very limited
manpower and free time based development it is actually
unbelievable how reliably Ekiga worked for me in the last
years. Now with 3.0 and new server more issues emerged
and your questions about how these could be prevented
are of course very important to ask.

> 
> This also raise question about the quality process for Ekiga. I do not
> count much on our users to perform such testing by themselves, except
> for obvious bugs like craches, totally broken feature, etc. Fortunately
> there is people like you taking time to report, but this is not the
> right way for most people who need a lot of guidance for it and who
> probably do not have the culture background to clearly see how much
> feedback is important for us.
> 
> I congrats you for being so insistant on this issue. Most people would
> have given up a long time ago.

Well, suddenly my relatives started to complain that they
cannot call me and I also noticed I could not call them
sometimes. That was enough to convince even a lazy man 
like me to have a closer look and report my findings :)

> 
> I think we should improve this part of our practise:
> http://wiki.ekiga.org/index.php/Pre-release_test
> 
> And I also need to set back up the daily snapshots/last stable for
> Ubuntu. So many work to do...
> 
> I think we should:
> 1- ease the process of reporting issues; waiting for people to show up
> in the right place, then asking for a -d 4 probably make it harder to
> report.
> 2- build up automatic testing/regression test for ekiga

I am sure both these points would help a lot. Regarding
1, I can think of several improvements (note that I am
not Ekiga developer so some of these may be wrong/
not possible/not feasible etc):
a) It should be possible to send the data from crash directly 
to Ekiga developers with one click. Similar thing as eg
Firefox handles this. Maybe it is already intended but when 
I get a crash, I only get the possiblity to save the log and
send it to an email address - hard to imagine that a usual
user would do that.
b) There could be an option in the GUI to deal with problems
and their reports. This would enable the user to turn on/off
log catching and in case it is turned on, to send it as
well as the report directly from the client.

Regarding 2, certainly something that would be very useful.
It could certainly not catch all the possible problems
but could still help a lot. At the beginning, something
simple like automatic periodic trunk/stable compilation,
running 2 instances on 2 locations and their automated 
periodic call making with detection of incoming sound and 
presence indication checked by sending parallel messages 
between these two computers could be of big help. Ssome
other things could be automatically tested also.

However, all of these would clearly take a _huge_ amount 
of time...

Palo



__________
http://cestovanie.sme.sk/ - Celý svet na vašom monitore


_______________________________________________
ekiga-list mailing list
ekiga-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/ekiga-list

<Prev in Thread] Current Thread [Next in Thread>