Pulseaudio version in Jessie

[Felipe Sateler]

Hi Niels, Release Team,

On Sat, Sep 13, 2014 at 7:13 AM, Niels Thykier <niels at thykier.net> wrote:
> On 2014-09-05 06:32, Felipe Sateler wrote:
>> Dear release team,
>>
>> I'm writing in order to discuss the status of Pulseaudio for Jessie.
>> Pulseaudio currently sits at (upstream) version 5 for jessie.
>>
>> [...]
>> So, the question is will we be able to ship pulseaudio 6? It is fairly
>> clear that the final release will not be on time for the freeze.
>> However, the release candidate may be introduced in time. The upstream
>> policy after a release candidate is only bug fixes and doc/translation
>> updates[3]. So I was thinking maybe an exception for the final release
>> could be made if the release candidate arrives early enough. We have
>> never managed a freeze I believe there are 2 main questions:
>>
>
>
> Hi Felipe / Pulseaudio maintainers,
>
> I apologise for the tardiness on our part.  Thanks for bringing this
> problem to our attention.
>
> If I understand you correctly then the consequence of the regression is
> Debian loses support for the following bluethooth devices:
>
>  1. "Health" devices
>     - I do not quite a clear view of what these are.  If you have an
>       example it would be nice.
>
>  2. Hands-free devices in Cars
>
> I presume that the lost support in question is "only" audio (which for
> the 2. part would still be very bad).

I'm not sure what Health devices are. But HSP support also means most
headphone+mic headsets.

>
>
>> 1. Is such a plan (uploading the RC pre-freeze and the final release
>> post-freeze) acceptable?
>
>
> For me, such a plan /could/ be acceptable provided that:
>
>  * The new major version of pulseaudio is both API and ABI backwards
>    compatible!
>
>    - A transition would be a deal-breaker for me at this point.

AFAICT, the ABI is maintained. I will check a bit more thoroughly and
report back, but I think this requirement is met.

>
>  * The current issues in the release candidates are not (new) RC bugs.
>
>    - Keep in mind that we may need to have pulseaudio reverted to the
>      old version should such issues turn out to be worse than
>      anticipated.

Of course. But we will not know the current issues in the release
candidate until we have it.

>
>  * You are aware that the Debian RT view of "necessary bug fixes" do
>    not always coincide with upstreams view of "necessary bug fixes".
>
>    - During the freeze we will reviewing all changes and we reserve the
>      right to question/reject any (part) of them.

How should I propose such changes? In order to make your work easier,
what should I send to the release list each time I upload a package?

>
>       - Keep in mind that we get more defensive as the freeze
>         progresses!
>
>    - You may have/want to cherry-pick changes frequently during the
>      freeze (at a much faster pace than upstream makes releases).

This sounds reasonable.

>    - You may have to support a "bastard" version for Jessie that
>      consists of the release candidate plus only (some) of upstreams
>      patches.

I would be fine with that. Not sure about the rest of the team.

>
>> 2. If so, when would be "early enough"? That is, until what date could
>> the RC be uploaded to Debian?
>>
>> [...]
>
> The sooner the better, although you may want to start with experimental
> to ensure it still builds on all architectures.
>
> *If* we go down this path (and I am *not* saying the release team is
> ready to commit to it), then I would highly prefer that we adopt the
> noblest of traditions in Open Source:
>
>   /Release early, release often./
>
> Smaller changes are (often) easier to review and has a higher chance of
> being accepted.

OK. As soon as the upstream release candidate is released I will
upload it to experimental. At that moment I will ping you again in
order to check you are still OK with following the above plan.


Thanks and keep up the good work

-- 

Saludos,
Felipe Sateler