Re: [Ekiga-devel-list] Setting the goals for Ekiga 3.4



Damien Sandras a écrit :
> Hi everyone,
> 
> 
> In the last few months, Ekiga has been evolving in various directions
> following the own will of each of its developers.
> 
> It is right that, on the contrary of other major Open Source projects,
> we are all coding in our spare time. The envy is great to do that the
> way we like it.
> 
> However, if we want the project to survive and to evolve in a *stable*
> way, I think it is important to define goals between releases.
> 
> Here are the goals I would like the project to reach for next release.
> I'm talking about user-visible changes, not about internal changes.
> Actually, things should be designed in Ekiga to improve the user
> experience, not the developer experience.
> 
> 1) Having the possibility to add to the roster people with more than one
> phone number (from the address book).
> 2) When a contact has been added from the address book, renaming it in
> the address book will trigger renaming in the roster. Changing contact
> information (cellphone number) will have the same effect.
> 3) A stable Pulse plugin, which will be the default. We will take the
> advantage of all Pulse features (stream tagging so that music is
> automatically stopped when receving or giving a phone call, and so on)
> 4) Having the ability to handle several calls simultaneously, with
> attended transfer support. (I need this at the office to take calls with
> Ekiga).
> 
> We should also work on related aspects :
> 1) Ekiga.org website
> 2) Ekiga.net website
> 3) Ekiga.net service

I aply for those last 3 entries. I still have a few work to do about
packaging, then I'll jump on that seriously.

> 
> Comments ?

I think it is a good idea to add TCP support; atm the lack of TCP
signaling for SIP broke some setups (calls fail), and as a packager I do
not package extra codecs (non free) because of this bug. This means
those non free codecs are undertested (e.g. it seems latest x264 lib do
not compile with Ekiga anymore), and we lose some interoperability with
other software/hardware out of the box.

I also think we should add some automatic workarounds. e.g. for
freephonie.net which only works if video is disabled. Those issues hurt
our reputation (even if the culprit is on the registrar side for not
supporting well enough the standard). We have discussed that with Eugen,
and he has some ideas to not clutter much our code... /me launching the
hot patato to Eugen ;)

Best regards,
Yannick


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]