[pulseaudio-discuss] Next pulseaudio release?

[Felipe Sateler]

On Thu, Sep 18, 2014 at 4:39 AM, Tanu Kaskinen
<tanu.kaskinen at linux.intel.com> wrote:
> On Tue, 2014-09-16 at 10:44 -0300, Felipe Sateler wrote:
>> On Thu, Sep 4, 2014 at 10:48 AM, Felipe Sateler <fsateler at debian.org> wrote:
>> > On Thu, Sep 4, 2014 at 5:39 AM, Tanu Kaskinen
>> > <tanu.kaskinen at linux.intel.com> wrote:
>> >> On Tue, 2014-09-02 at 11:17 -0400, Felipe Sateler wrote:
>> >>> On Tue, Sep 2, 2014 at 5:20 AM, Tanu Kaskinen
>> >>> <tanu.kaskinen at linux.intel.com> wrote:
>> >>> > On Wed, 2014-08-27 at 18:49 -0400, Felipe Sateler wrote:
>> >>> >> Hi all,
>> >>> >>
>> >>> >> The debian release team plans to freeze the next debian release on the
>> >>> >> 5th of November[1]. So I think it is good to plan ahead to see if we
>> >>> >> might be able to carry pulseaudio 6 in Jessie or will we have to stick
>> >>> >> with version 5.
>> >>> >>
>> >>> >> There is a 6.0 release bug[2] in the tracker, but it currently is only
>> >>> >> tracking 7 bugs, and I suspect the more important blockers for PA 6
>> >>> >> will be new features, which are not tracked in bugzilla. So I
>> >>> >> currently have no idea if the next PA release is relatively close or
>> >>> >> still very far away. If the next release is close, then we (debian)
>> >>> >> may need to start preparing for it.
>> >>> >>
>> >>> >> So the question for debian is: When is a reasonable ballpark estimate
>> >>> >> for a PA 6 release? I certainly don't expect a date to be known yet.
>> >>> >> But if you expect PA to be released Real Soon Now, there may be a
>> >>> >> possibility of including PA 6 in Jessie. If the release is probably
>> >>> >> next year then we will have to stick with version 5.
>> >>> >
>> >>> > The only thing that isn't listed in the 6.0 blockers list in the
>> >>> > bugzilla is the oFono patch set. My plan (which has not been agreed with
>> >>> > anyone else, so it's subject to discussion) has been to get that patch
>> >>> > set merged, fix the blocker bugs and then make the first release
>> >>> > candidate. From the first release candidate it has usually taken at
>> >>> > least a month before the final release happens. I expect the release to
>> >>> > happen this year, but I'm not 100% sure about that
>> >>>
>> >>> I will coordinate will the debian release team if it would be
>> >>> acceptable to land the rc just before the freeze, and then upload the
>> >>> final release after the freeze. But for that the release team is
>> >>> probably going to ask me what is the pulseaudio (upstream) policy on
>> >>> patch acceptance after the rc: Only bug fixes? Bug fixes + small
>> >>> improvements? Anything that looks good?
>> >>>
>> >>> A quick glance at the git log suggests bug fixes + translation/doc
>> >>> updates, but a confirmation would be great.
>> >>
>> >> "Bug fixes + translation/doc updates" sounds pretty accurate. Everything
>> >> else should go to a separate branch that is merged to master after the
>> >> final release.
>> >
>> > Great, I will contact the release team and report back the result.
>>
>> One release team member has answered[1]. Unfortunately, it is still
>> all depending on when is the release candidate released.
>>
>> One comment worth mentioning is that during the freeze the release
>> team has to ack every change. This means that if the RT judgment is
>> different from yours as upstream as to what acceptable means, we might
>> end up with an almost-6.0 version in jessie. Would you be OK with
>> that? Keep in mind we already carry some patches, although not very
>> intrusive.
>
> Yes, I would be OK with that.
>
>> [1] https://lists.debian.org/debian-release/2014/09/msg00172.html
>
> I read that thread, and it sounds like you might have a bit too
> optimistic view of the BlueZ situation. HFP support will require oFono,
> and I don't know if there are complications with making oFono installed
> in Debian's default configuration. Will it conflict with ModemManager?

I'm very ignorant on this point. I have never used oFono or ModemManager.

> oFono also requires a modem to be set up. AFAIK there's some dummy modem
> implementation that should be sufficient for getting HFP to work. I hope
> you can enable the dummy modem by default.
>
> Also, the oFono code in PulseAudio provides only HFP support, HSP isn't
> supported. Most headsets support both profiles, so this is perhaps not a
> huge issue, but see Georg Chini's complaints in the "[PATCH 0/5] Add
> simple HSP support in new native backend" thread.
>
> Wim Taymans wrote patches for supporting HSP without oFono, but that
> code is currently mutually exclusive with oFono support (a compile-time
> option), so PulseAudio can support either HSP or HFP, not both. Those
> patches have not been merged yet, and at least I'm not committed to
> reviewing those before the release (Arun already gave some feedback,
> though, so perhaps he will continue reviewing them).

So, if I understand correctly, the current situation is the following:

1. oFono patches have been fully merged.
2. Wim Taymans patches have not been merged yet (or at least not completely)
3. Even if Wim's patches are merged, we (debian) will have to choose
between oFono or native at compile time.
4. Either patchset is not complete, in that one supports HSP and the other HFP.
5. In practice, the above is not terribly important, because most
devices support both.
6. oFono requires manual configuration by the user.

With the above understanding, I'm thinking that we could work around
problem 3 by building pulseaudio twice and shipping the relevant
modules in separate conflicting packages. Not sure if that would be
too confusing for users.

If ofono requires manual configuration (and does the ofono support
have a minimum version requirement? Debian currently has 1.9), I think
it would be better for us to use the native backend, if it manages to
be upstreamed in time.

-- 

Saludos,
Felipe Sateler