Reorganizing things

[Damien Sandras]

Dear all,

It appears clearly that since a few months I can dedicate less time than
before to Ekiga. During the first 5 to 6 years of the project, I was
dedicating all evenings to the project and nearly all week-ends, fully.

It is now impossible for me to continue developing at that pace. If we
organize things in a clever way, I think it will not be a problem. My
intensive work probably hide a few organization problems.

We now have a few very high quality contributors: they help the project
move forward will less "devotion" from myself.

The purpose of this e-mail is to identify the areas where people can
help and how we should work. But before identifying those areas, I would
stress on the fact that my wish is to release often, but with only a
limited set of new features, that are well-tested. We have seen in the
past that we had worked on many new features, half-finished, and that it
was hard to stabilize them before doing a release. I don't want this to
happen.

Here is the list of tasks I have identified.

a) Reorganization of the WEB service (ekiga.org + ekiga.net) : it is a
much required work to give the feeling of a united and well thought
service. We need designers for that task.

b) Reorganization of ekiga.net services : more stability, more features.
I can take care of that myself, but external help would be great.

c) Accounts support : we receive many e-mails of people wanting to
remove their account or wondering why it does not work. They are not
answered anymore. We need somebody to help with that.

d) Development : we need more developers. Eugen is handling bugzilla and
patches. Julien is coding a lot. Michael is working on the WIN32 version
which is nearly as good as the Linux version. More people like all of
them should join the Ekiga project and help improving it.

e) Documentation : Yannick has been managing this since a few years
nearly alone. Help is welcome.

f) User Support : We all do user support at some level. When we do user
support, it means we can not dedicate time to our other tasks to make
the software progress. More people working on user support should join.
Perhaps a forum instead of a mailing list would be more modern and ease
the task.

Did I forget something?

Feel free to comment...
--
 _     Damien Sandras
(o-      
//\    Ekiga Softphone : http://www.ekiga.org/
v_/_   Be IP           : http://www.beip.be/
       FOSDEM          : http://www.fosdem.org/
       SIP Phone       : sip:dsandras@...
                       

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

[Peter Robinson]

Hi Damien,

> It appears clearly that since a few months I can dedicate less time than
> before to Ekiga. During the first 5 to 6 years of the project, I was
> dedicating all evenings to the project and nearly all week-ends, fully.

Thanks for all your dedication over the years. I've been using ekiga
for years and absolutely love it!

> It is now impossible for me to continue developing at that pace. If we
> organize things in a clever way, I think it will not be a problem. My
> intensive work probably hide a few organization problems.
>
> We now have a few very high quality contributors: they help the project
> move forward will less "devotion" from myself.
>
> The purpose of this e-mail is to identify the areas where people can
> help and how we should work. But before identifying those areas, I would
> stress on the fact that my wish is to release often, but with only a
> limited set of new features, that are well-tested. We have seen in the
> past that we had worked on many new features, half-finished, and that it
> was hard to stabilize them before doing a release. I don't want this to
> happen.
>
> Here is the list of tasks I have identified.
>
> a) Reorganization of the WEB service (ekiga.org + ekiga.net) : it is a
> much required work to give the feeling of a united and well thought
> service. We need designers for that task.
>
> b) Reorganization of ekiga.net services : more stability, more features.
> I can take care of that myself, but external help would be great.

I can assist from this side of things. I'm a Systems Engineer /
Technical Architect by trade and this is what i do for a living.

> c) Accounts support : we receive many e-mails of people wanting to
> remove their account or wondering why it does not work. They are not
> answered anymore. We need somebody to help with that.
>
> d) Development : we need more developers. Eugen is handling bugzilla and
> patches. Julien is coding a lot. Michael is working on the WIN32 version
> which is nearly as good as the Linux version. More people like all of
> them should join the Ekiga project and help improving it.
>
> e) Documentation : Yannick has been managing this since a few years
> nearly alone. Help is welcome.
>
> f) User Support : We all do user support at some level. When we do user
> support, it means we can not dedicate time to our other tasks to make
> the software progress. More people working on user support should join.
> Perhaps a forum instead of a mailing list would be more modern and ease
> the task.
>
> Did I forget something?

Not that I'm aware of.

Peter
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Damien Sandras]

Nobody ?

(Except Peter: thanks for the nice words and help offer!)

Le lundi 31 août 2009 à 19:58 +0200, Damien Sandras a écrit :

> Dear all,
>
> It appears clearly that since a few months I can dedicate less time than
> before to Ekiga. During the first 5 to 6 years of the project, I was
> dedicating all evenings to the project and nearly all week-ends, fully.
>
> It is now impossible for me to continue developing at that pace. If we
> organize things in a clever way, I think it will not be a problem. My
> intensive work probably hide a few organization problems.
>
> We now have a few very high quality contributors: they help the project
> move forward will less "devotion" from myself.
>
> The purpose of this e-mail is to identify the areas where people can
> help and how we should work. But before identifying those areas, I would
> stress on the fact that my wish is to release often, but with only a
> limited set of new features, that are well-tested. We have seen in the
> past that we had worked on many new features, half-finished, and that it
> was hard to stabilize them before doing a release. I don't want this to
> happen.
>
> Here is the list of tasks I have identified.
>
> a) Reorganization of the WEB service (ekiga.org + ekiga.net) : it is a
> much required work to give the feeling of a united and well thought
> service. We need designers for that task.
>
> b) Reorganization of ekiga.net services : more stability, more features.
> I can take care of that myself, but external help would be great.
>
> c) Accounts support : we receive many e-mails of people wanting to
> remove their account or wondering why it does not work. They are not
> answered anymore. We need somebody to help with that.
>
> d) Development : we need more developers. Eugen is handling bugzilla and
> patches. Julien is coding a lot. Michael is working on the WIN32 version
> which is nearly as good as the Linux version. More people like all of
> them should join the Ekiga project and help improving it.
>
> e) Documentation : Yannick has been managing this since a few years
> nearly alone. Help is welcome.
>
> f) User Support : We all do user support at some level. When we do user
> support, it means we can not dedicate time to our other tasks to make
> the software progress. More people working on user support should join.
> Perhaps a forum instead of a mailing list would be more modern and ease
> the task.
>
> Did I forget something?
>
> Feel free to comment...

--
 _     Damien Sandras
(o-      
//\    Ekiga Softphone : http://www.ekiga.org/
v_/_   Be IP           : http://www.beip.be/
       FOSDEM          : http://www.fosdem.org/
       SIP Phone       : sip:dsandras@...
                       

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

[Eugen Dedu]

Damien Sandras wrote:

> Dear all,
>
> It appears clearly that since a few months I can dedicate less time than
> before to Ekiga. During the first 5 to 6 years of the project, I was
> dedicating all evenings to the project and nearly all week-ends, fully.
>
> It is now impossible for me to continue developing at that pace. If we
> organize things in a clever way, I think it will not be a problem. My
> intensive work probably hide a few organization problems.
>
> We now have a few very high quality contributors: they help the project
> move forward will less "devotion" from myself.
>
> The purpose of this e-mail is to identify the areas where people can
> help and how we should work. But before identifying those areas, I would
> stress on the fact that my wish is to release often, but with only a
> limited set of new features, that are well-tested. We have seen in the
> past that we had worked on many new features, half-finished, and that it
> was hard to stabilize them before doing a release. I don't want this to
> happen.
>
> Here is the list of tasks I have identified.
>
> a) Reorganization of the WEB service (ekiga.org + ekiga.net) : it is a
> much required work to give the feeling of a united and well thought
> service. We need designers for that task.
>
> b) Reorganization of ekiga.net services : more stability, more features.
> I can take care of that myself, but external help would be great.
>
> c) Accounts support : we receive many e-mails of people wanting to
> remove their account or wondering why it does not work. They are not
> answered anymore. We need somebody to help with that.
>
> d) Development : we need more developers. Eugen is handling bugzilla and
> patches. Julien is coding a lot. Michael is working on the WIN32 version
> which is nearly as good as the Linux version. More people like all of
> them should join the Ekiga project and help improving it.
>
> e) Documentation : Yannick has been managing this since a few years
> nearly alone. Help is welcome.
>
> f) User Support : We all do user support at some level. When we do user
> support, it means we can not dedicate time to our other tasks to make
> the software progress. More people working on user support should join.
> Perhaps a forum instead of a mailing list would be more modern and ease
> the task.
>
> Did I forget something?
>
> Feel free to comment...

I agree with all you said!

What does a forum have and a mailing list does not?

--
Eugen
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Damien Sandras]

Le mardi 01 septembre 2009 à 10:38 +0200, Eugen Dedu a écrit :

> Damien Sandras wrote:
> > Dear all,
> >
> > It appears clearly that since a few months I can dedicate less time than
> > before to Ekiga. During the first 5 to 6 years of the project, I was
> > dedicating all evenings to the project and nearly all week-ends, fully.
> >
> > It is now impossible for me to continue developing at that pace. If we
> > organize things in a clever way, I think it will not be a problem. My
> > intensive work probably hide a few organization problems.
> >
> > We now have a few very high quality contributors: they help the project
> > move forward will less "devotion" from myself.
> >
> > The purpose of this e-mail is to identify the areas where people can
> > help and how we should work. But before identifying those areas, I would
> > stress on the fact that my wish is to release often, but with only a
> > limited set of new features, that are well-tested. We have seen in the
> > past that we had worked on many new features, half-finished, and that it
> > was hard to stabilize them before doing a release. I don't want this to
> > happen.
> >
> > Here is the list of tasks I have identified.
> >
> > a) Reorganization of the WEB service (ekiga.org + ekiga.net) : it is a
> > much required work to give the feeling of a united and well thought
> > service. We need designers for that task.
> >
> > b) Reorganization of ekiga.net services : more stability, more features.
> > I can take care of that myself, but external help would be great.
> >
> > c) Accounts support : we receive many e-mails of people wanting to
> > remove their account or wondering why it does not work. They are not
> > answered anymore. We need somebody to help with that.
> >
> > d) Development : we need more developers. Eugen is handling bugzilla and
> > patches. Julien is coding a lot. Michael is working on the WIN32 version
> > which is nearly as good as the Linux version. More people like all of
> > them should join the Ekiga project and help improving it.
> >
> > e) Documentation : Yannick has been managing this since a few years
> > nearly alone. Help is welcome.
> >
> > f) User Support : We all do user support at some level. When we do user
> > support, it means we can not dedicate time to our other tasks to make
> > the software progress. More people working on user support should join.
> > Perhaps a forum instead of a mailing list would be more modern and ease
> > the task.
> >
> > Did I forget something?
> >
> > Feel free to comment...
>
> I agree with all you said!
>
> What does a forum have and a mailing list does not?

Wouldn't it be more user-friendly for the lambda user ?
--
 _     Damien Sandras
(o-      
//\    Ekiga Softphone : http://www.ekiga.org/
v_/_   Be IP           : http://www.beip.be/
       FOSDEM          : http://www.fosdem.org/
       SIP Phone       : sip:dsandras@...
                       

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

[Thierry Simonnet]

Damien Sandras wrote:

> Dear all,
>
> It appears clearly that since a few months I can dedicate less time than
> before to Ekiga. During the first 5 to 6 years of the project, I was
> dedicating all evenings to the project and nearly all week-ends, fully.
>
> It is now impossible for me to continue developing at that pace. If we
> organize things in a clever way, I think it will not be a problem. My
> intensive work probably hide a few organization problems.
>
> We now have a few very high quality contributors: they help the project
> move forward will less "devotion" from myself.
>
> The purpose of this e-mail is to identify the areas where people can
> help and how we should work. But before identifying those areas, I would
> stress on the fact that my wish is to release often, but with only a
> limited set of new features, that are well-tested. We have seen in the
> past that we had worked on many new features, half-finished, and that it
> was hard to stabilize them before doing a release. I don't want this to
> happen.
>
> Here is the list of tasks I have identified.
>
> a) Reorganization of the WEB service (ekiga.org + ekiga.net) : it is a
> much required work to give the feeling of a united and well thought
> service. We need designers for that task.
>
> b) Reorganization of ekiga.net services : more stability, more features.
> I can take care of that myself, but external help would be great.
>
> c) Accounts support : we receive many e-mails of people wanting to
> remove their account or wondering why it does not work. They are not
> answered anymore. We need somebody to help with that.
>
> d) Development : we need more developers. Eugen is handling bugzilla and
> patches. Julien is coding a lot. Michael is working on the WIN32 version
> which is nearly as good as the Linux version. More people like all of
> them should join the Ekiga project and help improving it.
>
> e) Documentation : Yannick has been managing this since a few years
> nearly alone. Help is welcome.
>
> f) User Support : We all do user support at some level. When we do user
> support, it means we can not dedicate time to our other tasks to make
> the software progress. More people working on user support should join.
> Perhaps a forum instead of a mailing list would be more modern and ease
> the task.
>
> Did I forget something?
>
> Feel free to comment...
>  

I agree with these points.
Perhaps splitting development and maintenance could be convenient for
version management.

--

Thierry Simonnet

ESIEE-Paris

Par respect pour l’environnement, n’imprimez ce mail que si nécessaire


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

[Julien PUYDT]

Eugen Dedu a écrit :
> What does a forum have and a mailing list does not?

I never saw the search in the mailing-list archives work...

Snark

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

[Eugen Dedu]

Julien Puydt wrote:
> Eugen Dedu a écrit :
>> What does a forum have and a mailing list does not?
>
> I never saw the search in the mailing-list archives work...

www.google.com?  It searches in mailing lists, wiki etc.

--
Eugen
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Yannick-GNU/Linux]

Eugen Dedu a écrit :
> Julien Puydt wrote:
>> Eugen Dedu a écrit :
>>> What does a forum have and a mailing list does not?
>> I never saw the search in the mailing-list archives work...
>
> www.google.com?  It searches in mailing lists, wiki etc.
>

Eugen, you're assuming too much. It is indeed easier to search a forum.
Just one tool and one interface.

Beside some people are not used to email clients as we are, but most
poeple are used to the web.

A forum is also a better tool to manage a community: you can give some
rights to people to manage the forum, people can use it without any
registration, you can classify discussions in some subforum much more
easily than with mailing-list, even open some subforum for a dedicated
langage. And you can have the messages from the forum into your mail box
too. Finaly, it is more eye-candy.

The downside, is some people have to manage it. And it is probably more
work than a mailling list. Still, as the goel is to get more people
involve, I think a forum is better.

And finaly, it is possible to integrate forum, ekiga.net, ekiga.org and
the wiki in just one interface. But that needs some dev work.

I think a forum is a good idea.
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Yannick-GNU/Linux]

Damien Sandras a écrit :
> Nobody ?
>

Sorry, it is a bad timefor me as my work is starting again; I'll have
fewer spare time for 2 or 3 weeks...

> (Except Peter: thanks for the nice words and help offer!)
>
> Le lundi 31 août 2009 à 19:58 +0200, Damien Sandras a écrit :
>> Dear all,
>>
>> It appears clearly that since a few months I can dedicate less time than
>> before to Ekiga. During the first 5 to 6 years of the project, I was
>> dedicating all evenings to the project and nearly all week-ends, fully.
>>
>> It is now impossible for me to continue developing at that pace. If we
>> organize things in a clever way, I think it will not be a problem. My
>> intensive work probably hide a few organization problems.
>>
>> We now have a few very high quality contributors: they help the project
>> move forward will less "devotion" from myself.
>>
>> The purpose of this e-mail is to identify the areas where people can
>> help and how we should work. But before identifying those areas, I would
>> stress on the fact that my wish is to release often, but with only a
>> limited set of new features, that are well-tested. We have seen in the
>> past that we had worked on many new features, half-finished, and that it
>> was hard to stabilize them before doing a release. I don't want this to
>> happen.

I like this idea too, 3.0 was a pain to release. Beside, network (TCP
support) and the audio part of Ekiga (e.g. pulse audio) needs some new
features quickly.

>>
>> Here is the list of tasks I have identified.
>>
>> a) Reorganization of the WEB service (ekiga.org + ekiga.net) : it is a
>> much required work to give the feeling of a united and well thought
>> service. We need designers for that task.

I'll do some work for it soon. first, I'll start with a theme maching
current ekiga.org for drupal.

>>
>> b) Reorganization of ekiga.net services : more stability, more features.
>> I can take care of that myself, but external help would be great.
>>
>> c) Accounts support : we receive many e-mails of people wanting to
>> remove their account or wondering why it does not work. They are not
>> answered anymore. We need somebody to help with that.

Indeed, I do not really respond to all requests, still it is also in my
plan to improve ekiga.net with deletion of account and a new password
design (design is done, implementation is the next step)

>>
>> d) Development : we need more developers. Eugen is handling bugzilla and
>> patches. Julien is coding a lot. Michael is working on the WIN32 version
>> which is nearly as good as the Linux version. More people like all of
>> them should join the Ekiga project and help improving it.
>>
>> e) Documentation : Yannick has been managing this since a few years
>> nearly alone. Help is welcome.

I'll do some work for it too, but ekiga.net and ekiga.org reshaping will
come first. I think our website is the best meeting point for users and
devs willing to help. It really needs improvements.

>>
>> f) User Support : We all do user support at some level. When we do user
>> support, it means we can not dedicate time to our other tasks to make
>> the software progress. More people working on user support should join.
>> Perhaps a forum instead of a mailing list would be more modern and ease
>> the task.

As ekiga does not report errors in a very distinctive way, support is
hard to do for people which cannot read a -d 4. A forum will not fix
that. I think some dev is needed in ekiga (e.g. a debug console).

>>
>> Did I forget something?
>>

I will add testing: testing before a release, testing interoperability,
and testing new features in the master tree in coordination with devs in
charge.

Best regards,
Yannick

>> Feel free to comment...

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

[Peter Robinson]

> Sorry, it is a bad timefor me as my work is starting again; I'll have
> fewer spare time for 2 or 3 weeks...
>
>> (Except Peter: thanks for the nice words and help offer!)
>>
>> Le lundi 31 août 2009 à 19:58 +0200, Damien Sandras a écrit :
>>> Dear all,
>>>
>>> It appears clearly that since a few months I can dedicate less time than
>>> before to Ekiga. During the first 5 to 6 years of the project, I was
>>> dedicating all evenings to the project and nearly all week-ends, fully.
>>>
>>> It is now impossible for me to continue developing at that pace. If we
>>> organize things in a clever way, I think it will not be a problem. My
>>> intensive work probably hide a few organization problems.
>>>
>>> We now have a few very high quality contributors: they help the project
>>> move forward will less "devotion" from myself.
>>>
>>> The purpose of this e-mail is to identify the areas where people can
>>> help and how we should work. But before identifying those areas, I would
>>> stress on the fact that my wish is to release often, but with only a
>>> limited set of new features, that are well-tested. We have seen in the
>>> past that we had worked on many new features, half-finished, and that it
>>> was hard to stabilize them before doing a release. I don't want this to
>>> happen.
>
> I like this idea too, 3.0 was a pain to release. Beside, network (TCP
> support) and the audio part of Ekiga (e.g. pulse audio) needs some new
> features quickly.

From a Fedora point of view the two "bugs" I see on a regular basis
are "Audio Problems" (will be fixed mostly by a Pulse Audio plugin set
as the default) and Network issues which are mostly Firewall and NAT
based. I think support for upnp would possibly fix most of those
issues for the average user. The would be the most useful features
from my point of view and the later would probably also help the issue
with ekiga.net "not working" mentioned elsewhere.

Peter
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Yannick-GNU/Linux]

Peter Robinson a écrit :

>> Sorry, it is a bad timefor me as my work is starting again; I'll have
>> fewer spare time for 2 or 3 weeks...
>>
>>> (Except Peter: thanks for the nice words and help offer!)
>>>
>>> Le lundi 31 août 2009 à 19:58 +0200, Damien Sandras a écrit :
>>>> Dear all,
>>>>
>>>> It appears clearly that since a few months I can dedicate less time than
>>>> before to Ekiga. During the first 5 to 6 years of the project, I was
>>>> dedicating all evenings to the project and nearly all week-ends, fully.
>>>>
>>>> It is now impossible for me to continue developing at that pace. If we
>>>> organize things in a clever way, I think it will not be a problem. My
>>>> intensive work probably hide a few organization problems.
>>>>
>>>> We now have a few very high quality contributors: they help the project
>>>> move forward will less "devotion" from myself.
>>>>
>>>> The purpose of this e-mail is to identify the areas where people can
>>>> help and how we should work. But before identifying those areas, I would
>>>> stress on the fact that my wish is to release often, but with only a
>>>> limited set of new features, that are well-tested. We have seen in the
>>>> past that we had worked on many new features, half-finished, and that it
>>>> was hard to stabilize them before doing a release. I don't want this to
>>>> happen.
>> I like this idea too, 3.0 was a pain to release. Beside, network (TCP
>> support) and the audio part of Ekiga (e.g. pulse audio) needs some new
>> features quickly.
>
>>From a Fedora point of view the two "bugs" I see on a regular basis
> are "Audio Problems" (will be fixed mostly by a Pulse Audio plugin set
> as the default) and Network issues which are mostly Firewall and NAT
> based. I think support for upnp would possibly fix most of those
> issues for the average user. The would be the most useful features
> from my point of view and the later would probably also help the issue
> with ekiga.net "not working" mentioned elsewhere.
>

I see pulse audio as a good thing for the Linux audio stack; it provide
a unified test case of the major features and my hope is to see it
improve the situation at the end. (and IMHO it really needs improvements...)

The network issue is also a complex matter. I agree upnp will improve
the situation too. Still it will not be enough for some people. The
software we compete with here (skype) is full of workarounds for
hardware/network config *hostile* to VoIP. As people with software which
do not work are always louder than people where it just work, the
situation will still harm ekiga reputation. Beside, the security topic
here is quite important and very complex, and this is something skype
deals with obscurity. Quite frankly, I doubt if the skype protocol was
open, it will be considered as secure... I've started to work on the
topic, i.e. how to deal with hardware/setup hostile to VoIP. I've hope
to publish a white paper in the coming months (I was full of hope to
publish this for the end of august, but I was then busy with user
support, bug triaging, packages, etc.). I do not see a good fix for that
in the short term. Any help is welcome.

> Peter
> _______________________________________________
> Ekiga-devel-list mailing list
> Ekiga-devel-list@...
> http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
>
>

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

[Dave Allan]

I hesitate a little to speak here, as I'm not completely versed in the
issues or the code, but here's a short statement of my experience with
these two problems on Fedora 10 using the SVN head as of about a week
ago.  The head from this morning crashes when I try to make calls, so I
can't say if the behavior has changed since then.  See the rest of my
comments inline, below.  I would be happy to file bugs against these
behaviors if that would be helpful, or work with someone familiar with
the code to troubleshoot them further.

yannick wrote:

> Peter Robinson a écrit :
>>> Sorry, it is a bad timefor me as my work is starting again; I'll have
>>> fewer spare time for 2 or 3 weeks...
>>>
>>>> (Except Peter: thanks for the nice words and help offer!)
>>>>
>>>> Le lundi 31 août 2009 à 19:58 +0200, Damien Sandras a écrit :
>>>>> Dear all,
>>>>>
>>>>> It appears clearly that since a few months I can dedicate less time than
>>>>> before to Ekiga. During the first 5 to 6 years of the project, I was
>>>>> dedicating all evenings to the project and nearly all week-ends, fully.
>>>>>
>>>>> It is now impossible for me to continue developing at that pace. If we
>>>>> organize things in a clever way, I think it will not be a problem. My
>>>>> intensive work probably hide a few organization problems.
>>>>>
>>>>> We now have a few very high quality contributors: they help the project
>>>>> move forward will less "devotion" from myself.
>>>>>
>>>>> The purpose of this e-mail is to identify the areas where people can
>>>>> help and how we should work. But before identifying those areas, I would
>>>>> stress on the fact that my wish is to release often, but with only a
>>>>> limited set of new features, that are well-tested. We have seen in the
>>>>> past that we had worked on many new features, half-finished, and that it
>>>>> was hard to stabilize them before doing a release. I don't want this to
>>>>> happen.
>>> I like this idea too, 3.0 was a pain to release. Beside, network (TCP
>>> support) and the audio part of Ekiga (e.g. pulse audio) needs some new
>>> features quickly.
>> >From a Fedora point of view the two "bugs" I see on a regular basis
>> are "Audio Problems" (will be fixed mostly by a Pulse Audio plugin set
>> as the default) and Network issues which are mostly Firewall and NAT
>> based. I think support for upnp would possibly fix most of those
>> issues for the average user. The would be the most useful features
>> from my point of view and the later would probably also help the issue
>> with ekiga.net "not working" mentioned elsewhere.
>>
>
> I see pulse audio as a good thing for the Linux audio stack; it provide
> a unified test case of the major features and my hope is to see it
> improve the situation at the end. (and IMHO it really needs improvements...)

Pulse support in the SVN head as of a week or so ago is only partially
functional.  When I place a call, I hear ekiga generate the ring sound
until the other end picks up the call.  The other end hears only digital
artifacts (soft blip-blip-blip noises) until I open the pulse audio
volume control application, at which point the other end hears correct
audio.  Closing the volume control application reverts to digital
artifacts.  Reopening it causes audio to work again.  I never hear audio
from the called party.  These behaviors are 100% reproducible.

> The network issue is also a complex matter. I agree upnp will improve
> the situation too. Still it will not be enough for some people. The
> software we compete with here (skype) is full of workarounds for
> hardware/network config *hostile* to VoIP. As people with software which
> do not work are always louder than people where it just work, the
> situation will still harm ekiga reputation. Beside, the security topic
> here is quite important and very complex, and this is something skype
> deals with obscurity. Quite frankly, I doubt if the skype protocol was
> open, it will be considered as secure... I've started to work on the
> topic, i.e. how to deal with hardware/setup hostile to VoIP. I've hope
> to publish a white paper in the coming months (I was full of hope to
> publish this for the end of august, but I was then busy with user
> support, bug triaging, packages, etc.). I do not see a good fix for that
> in the short term. Any help is welcome.

On Fedora 10, I have a machine with several interfaces including a VPN
interface.  I am only intermittently able to register and make calls
through my SIP server.  Checking the box in preferences at:

Edit->Preferences->General->General Settings->Network Settings->Enable
network detection

seems to have a positive effect, in other words, ekiga seems more likely
to register and place calls when that box is checked, but it's not 100%
effective.

If I create a virtual machine on this physical machine, ekiga registers
and makes calls 100% of the time.  Both machines are running F10, fully
updated.  The significant difference is that the VM has only one
interface, plus loopback, whereas the physical host has 5 interfaces
plus loopback.

Twinkle registers and places calls reliably from this machine.  I don't
know the twinkle code, either, but since it is FOSS, perhaps it would be
useful to look at its code to see how it operates in the multi-interface
case.

Dave
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Eugen Dedu]

Dave Allan wrote:

> I hesitate a little to speak here, as I'm not completely versed in the
> issues or the code, but here's a short statement of my experience with
> these two problems on Fedora 10 using the SVN head as of about a week
> ago.  The head from this morning crashes when I try to make calls, so I
> can't say if the behavior has changed since then.  See the rest of my
> comments inline, below.  I would be happy to file bugs against these
> behaviors if that would be helpful, or work with someone familiar with
> the code to troubleshoot them further.
>
> yannick wrote:
>> Peter Robinson a écrit :
>>>> Sorry, it is a bad timefor me as my work is starting again; I'll have
>>>> fewer spare time for 2 or 3 weeks...
>>>>
>>>>> (Except Peter: thanks for the nice words and help offer!)
>>>>>
>>>>> Le lundi 31 août 2009 à 19:58 +0200, Damien Sandras a écrit :
>>>>>> Dear all,
>>>>>>
>>>>>> It appears clearly that since a few months I can dedicate less
>>>>>> time than
>>>>>> before to Ekiga. During the first 5 to 6 years of the project, I was
>>>>>> dedicating all evenings to the project and nearly all week-ends,
>>>>>> fully.
>>>>>>
>>>>>> It is now impossible for me to continue developing at that pace.
>>>>>> If we
>>>>>> organize things in a clever way, I think it will not be a problem. My
>>>>>> intensive work probably hide a few organization problems.
>>>>>>
>>>>>> We now have a few very high quality contributors: they help the
>>>>>> project
>>>>>> move forward will less "devotion" from myself.
>>>>>>
>>>>>> The purpose of this e-mail is to identify the areas where people can
>>>>>> help and how we should work. But before identifying those areas, I
>>>>>> would
>>>>>> stress on the fact that my wish is to release often, but with only a
>>>>>> limited set of new features, that are well-tested. We have seen in
>>>>>> the
>>>>>> past that we had worked on many new features, half-finished, and
>>>>>> that it
>>>>>> was hard to stabilize them before doing a release. I don't want
>>>>>> this to
>>>>>> happen.
>>>> I like this idea too, 3.0 was a pain to release. Beside, network (TCP
>>>> support) and the audio part of Ekiga (e.g. pulse audio) needs some new
>>>> features quickly.
>>> >From a Fedora point of view the two "bugs" I see on a regular basis
>>> are "Audio Problems" (will be fixed mostly by a Pulse Audio plugin set
>>> as the default) and Network issues which are mostly Firewall and NAT
>>> based. I think support for upnp would possibly fix most of those
>>> issues for the average user. The would be the most useful features
>>> from my point of view and the later would probably also help the issue
>>> with ekiga.net "not working" mentioned elsewhere.
>>>
>>
>> I see pulse audio as a good thing for the Linux audio stack; it provide
>> a unified test case of the major features and my hope is to see it
>> improve the situation at the end. (and IMHO it really needs
>> improvements...)
>
> Pulse support in the SVN head as of a week or so ago is only partially
> functional.  When I place a call, I hear ekiga generate the ring sound
> until the other end picks up the call.  The other end hears only digital
> artifacts (soft blip-blip-blip noises) until I open the pulse audio
> volume control application, at which point the other end hears correct
> audio.  Closing the volume control application reverts to digital
> artifacts.  Reopening it causes audio to work again.  I never hear audio
> from the called party.  These behaviors are 100% reproducible.

Could you please use latest svn for audio volume?  As for stability, we
know the trunk is not stable, please wait...

>> The network issue is also a complex matter. I agree upnp will improve
>> the situation too. Still it will not be enough for some people. The
>> software we compete with here (skype) is full of workarounds for
>> hardware/network config *hostile* to VoIP. As people with software which
>> do not work are always louder than people where it just work, the
>> situation will still harm ekiga reputation. Beside, the security topic
>> here is quite important and very complex, and this is something skype
>> deals with obscurity. Quite frankly, I doubt if the skype protocol was
>> open, it will be considered as secure... I've started to work on the
>> topic, i.e. how to deal with hardware/setup hostile to VoIP. I've hope
>> to publish a white paper in the coming months (I was full of hope to
>> publish this for the end of august, but I was then busy with user
>> support, bug triaging, packages, etc.). I do not see a good fix for that
>> in the short term. Any help is welcome.
>
> On Fedora 10, I have a machine with several interfaces including a VPN
> interface.  I am only intermittently able to register and make calls
> through my SIP server.  Checking the box in preferences at:
>
> Edit->Preferences->General->General Settings->Network Settings->Enable
> network detection
>
> seems to have a positive effect, in other words, ekiga seems more likely
> to register and place calls when that box is checked, but it's not 100%
> effective.
>
> If I create a virtual machine on this physical machine, ekiga registers
> and makes calls 100% of the time.  Both machines are running F10, fully
> updated.  The significant difference is that the VM has only one
> interface, plus loopback, whereas the physical host has 5 interfaces
> plus loopback.
>
> Twinkle registers and places calls reliably from this machine.  I don't
> know the twinkle code, either, but since it is FOSS, perhaps it would be
> useful to look at its code to see how it operates in the multi-interface
> case.

Yes, I think we should analyse the cases with several interfaces, there
is a bug report on this
http://bugzilla.gnome.org/show_bug.cgi?id=587504, but this will happen
later, maybe in one month...

--
Eugen
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Dave Allan]

Eugen Dedu wrote:

> Dave Allan wrote:
>> Pulse support in the SVN head as of a week or so ago is only partially
>> functional.  When I place a call, I hear ekiga generate the ring sound
>> until the other end picks up the call.  The other end hears only digital
>> artifacts (soft blip-blip-blip noises) until I open the pulse audio
>> volume control application, at which point the other end hears correct
>> audio.  Closing the volume control application reverts to digital
>> artifacts.  Reopening it causes audio to work again.  I never hear audio
>> from the called party.  These behaviors are 100% reproducible.
>
> Could you please use latest svn for audio volume?  As for stability, we
> know the trunk is not stable, please wait...

I'll wait for the trunk to stabilize and try again & let you know.

  > Yes, I think we should analyse the cases with several interfaces, there
> is a bug report on this
> http://bugzilla.gnome.org/show_bug.cgi?id=587504, but this will happen
> later, maybe in one month...

If there's anything I can do to try to help with the test effort, let me
know.  I seem to have one of the problematic configurations.  I don't
have the bandwidth at the moment to learn the codebase myself, but I do
have a build environment set up and I'm very willing to try out
experimental patches.

Dave

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

[Eugen Dedu]

Dave Allan wrote:

> Eugen Dedu wrote:
>> Dave Allan wrote:
>>> Pulse support in the SVN head as of a week or so ago is only partially
>>> functional.  When I place a call, I hear ekiga generate the ring sound
>>> until the other end picks up the call.  The other end hears only digital
>>> artifacts (soft blip-blip-blip noises) until I open the pulse audio
>>> volume control application, at which point the other end hears correct
>>> audio.  Closing the volume control application reverts to digital
>>> artifacts.  Reopening it causes audio to work again.  I never hear audio
>>> from the called party.  These behaviors are 100% reproducible.
>>
>> Could you please use latest svn for audio volume?  As for stability, we
>> know the trunk is not stable, please wait...
>
> I'll wait for the trunk to stabilize and try again & let you know.

Could you at least just update ekiga to today's git and tell if the
audio works well?

>  > Yes, I think we should analyse the cases with several interfaces, there
>> is a bug report on this
>> http://bugzilla.gnome.org/show_bug.cgi?id=587504, but this will happen
>> later, maybe in one month...
>
> If there's anything I can do to try to help with the test effort, let me
> know.  I seem to have one of the problematic configurations.  I don't
> have the bandwidth at the moment to learn the codebase myself, but I do
> have a build environment set up and I'm very willing to try out
> experimental patches.

Well, I do not know how to tackle these problems.  Maybe the best is to
get as much testcases as possible (search in mailing lists and ekiga
bugzilla, and maybe other -zilla too), analyse why they do not work
(comparison with other programs is welcome) based on packets exchanged,
and propose solutions...

--
Eugen
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Damien Sandras]

Le mercredi 02 septembre 2009 à 10:15 +0200, yannick a écrit :

> >>From a Fedora point of view the two "bugs" I see on a regular basis
> > are "Audio Problems" (will be fixed mostly by a Pulse Audio plugin set
> > as the default) and Network issues which are mostly Firewall and NAT
> > based. I think support for upnp would possibly fix most of those
> > issues for the average user. The would be the most useful features
> > from my point of view and the later would probably also help the issue
> > with ekiga.net "not working" mentioned elsewhere.
> >
>
> I see pulse audio as a good thing for the Linux audio stack; it provide
> a unified test case of the major features and my hope is to see it
> improve the situation at the end. (and IMHO it really needs improvements...)

The problem is that it is not designed for VoIP applications: it adds
latency.

> The network issue is also a complex matter. I agree upnp will improve
> the situation too. Still it will not be enough for some people. The

In Belgium, I've never seen a router supporting upnp...

> software we compete with here (skype) is full of workarounds for
> hardware/network config *hostile* to VoIP. As people with software which
> do not work are always louder than people where it just work, the
> situation will still harm ekiga reputation. Beside, the security topic
> here is quite important and very complex, and this is something skype
> deals with obscurity. Quite frankly, I doubt if the skype protocol was
> open, it will be considered as secure... I've started to work on the
> topic, i.e. how to deal with hardware/setup hostile to VoIP. I've hope
> to publish a white paper in the coming months (I was full of hope to
> publish this for the end of august, but I was then busy with user
> support, bug triaging, packages, etc.). I do not see a good fix for that
> in the short term. Any help is welcome.

I plan to detect that at some point, and redirect people through a
proxy. However, I'm not sure about the load and bandwidth in that case.
--
 _     Damien Sandras
(o-      
//\    Ekiga Softphone : http://www.ekiga.org/
v_/_   Be IP           : http://www.beip.be/
       FOSDEM          : http://www.fosdem.org/
       SIP Phone       : sip:dsandras@...
                       

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

[Dave Allan]

Damien Sandras wrote:

> Le mercredi 02 septembre 2009 à 10:15 +0200, yannick a écrit :
>>> >From a Fedora point of view the two "bugs" I see on a regular basis
>>> are "Audio Problems" (will be fixed mostly by a Pulse Audio plugin set
>>> as the default) and Network issues which are mostly Firewall and NAT
>>> based. I think support for upnp would possibly fix most of those
>>> issues for the average user. The would be the most useful features
>>> from my point of view and the later would probably also help the issue
>>> with ekiga.net "not working" mentioned elsewhere.
>>>
>> I see pulse audio as a good thing for the Linux audio stack; it provide
>> a unified test case of the major features and my hope is to see it
>> improve the situation at the end. (and IMHO it really needs improvements...)
>
> The problem is that it is not designed for VoIP applications: it adds
> latency.

I don't think the latency introduced by pulse is a big problem.  Pulse,
especially in its early days, had its warts, but I find its performance
to be acceptable now.  I've used pulse for VoIP and the latency is fine.
  Pulse obviously isn't the only solution, but it's a viable option and
important those of us on systems that use it.

Dave
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Peter Robinson]

On Thu, Sep 3, 2009 at 8:36 AM, Damien Sandras <dsandras@...> wrote:

> Le mercredi 02 septembre 2009 à 10:15 +0200, yannick a écrit :
>> >>From a Fedora point of view the two "bugs" I see on a regular basis
>> > are "Audio Problems" (will be fixed mostly by a Pulse Audio plugin set
>> > as the default) and Network issues which are mostly Firewall and NAT
>> > based. I think support for upnp would possibly fix most of those
>> > issues for the average user. The would be the most useful features
>> > from my point of view and the later would probably also help the issue
>> > with ekiga.net "not working" mentioned elsewhere.
>> >
>>
>> I see pulse audio as a good thing for the Linux audio stack; it provide
>> a unified test case of the major features and my hope is to see it
>> improve the situation at the end. (and IMHO it really needs improvements...)
>
> The problem is that it is not designed for VoIP applications: it adds
> latency.
>
>> The network issue is also a complex matter. I agree upnp will improve
>> the situation too. Still it will not be enough for some people. The
>
> In Belgium, I've never seen a router supporting upnp...

Interesting. I believe from friends that some devices like the PS3
require upnp to work well. I don't have one to verify. The router I
have happens to work very well because it understands SIP and deals
with the forwarding. I have a fairly dumb SIP handset and I can
send/receive calls with it using no special config at all.

>> software we compete with here (skype) is full of workarounds for
>> hardware/network config *hostile* to VoIP. As people with software which
>> do not work are always louder than people where it just work, the
>> situation will still harm ekiga reputation. Beside, the security topic
>> here is quite important and very complex, and this is something skype
>> deals with obscurity. Quite frankly, I doubt if the skype protocol was
>> open, it will be considered as secure... I've started to work on the
>> topic, i.e. how to deal with hardware/setup hostile to VoIP. I've hope
>> to publish a white paper in the coming months (I was full of hope to
>> publish this for the end of august, but I was then busy with user
>> support, bug triaging, packages, etc.). I do not see a good fix for that
>> in the short term. Any help is welcome.
>
> I plan to detect that at some point, and redirect people through a
> proxy. However, I'm not sure about the load and bandwidth in that case.

Not sure how well that would work in a corporate environment and what
they would think of that sort of config.

As a side note I've just discovered the libnice library [1] that
implements "IETF's draft Interactice Connectivity Establishment
standard (ICE)", a standard that I've never heard of but the telepathy
IM stack is using it. I only discovered it because I had to recompile
it in Fedora as part of a group of packages I maintain.

Peter

[1] http://nice.freedesktop.org/wiki/
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list