Hi Niels, Release Team, On Sat, Sep 13, 2014 at 7:13 AM, Niels Thykier <ni...@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 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAfdZj_AMXrY9PMzHPWiLKZncibdGYvSRnZi=suncqnwdwo...@mail.gmail.com
