What do do regarding the freeze?

[Martin Steghöfer]

Hi Petter!

Petter Reinholdtsen wrote:
> No-one with comments about these questions? 

Yes, I do have comments. I'm just a little busy with (paid) work right 
now. I'm sorry for the delay.

> Try to get them past the release
> managers into Jessie, or hold them back and upload to experimental in
> the mean time?

In the case of "holding back" you are suggesting "experimental" instead 
of "unstable", so we keep "unstable" clean of changes we won't get into 
Jessie, so we can easily fix possible RC bugs via "unstable" during the 
freeze?

> The changes to libvorbis is probably possible to get past the release
> managers.

I agree. An invalid memory access can crash the whole application that 
uses it, so that could qualify for severity "important".

> I am more unsure about vorbis-tool, as the changes at first
> sight seem to be quite extensive.  In reality, it is partly patch
> renaming and a few new patches.  Martin, do you feel like trying to
> get the vorbis-tools changes past the release managers?

Not in its current shape. Not only does the patch refactoring obstruct 
the view of the actual changes (and should be excluded, as you said) and 
is actually something mentioned explicitly as "Don't" in the freeze 
policy, but some of the actual fixes can also be seen of minor 
importance. I'd do the following about the 4 commits that haven't been 
released yet:

1. Patch refactoring: Should clearly be excluded.

2. Sampling rate sanity check to avoid crash: I don't think I can 
justify a priority above "normal" for this one. Although the bug can 
make the program crash, it only does so for files that wouldn't have 
been transcoded anyway. It's also about a stand-alone application, so 
the crash doesn't have an effect that goes beyond not transcoding the 
file. Apart from the error message there is no difference from the user 
perspective. The only reason why this got reported at all is that Mayhem 
specifically looked for weaknesses.

3. Ogg123 freeze when interrupting at EOS: This has a realistic chance 
to be included. The program freeze has a realistic chance to happen (it 
doesn't take a very precise timing to evoke it) and although the freeze 
always happens at the end of a file, there may be more files in the 
current playlist. I think this qualifies for severity "important".

4. Documentation of "-f + -d": This isn't very important in itself, but 
could "slip in" together with patch 3 as "documentation fixes, via TPU 
when included with other TPU-applicable fixes." (criterion IV of the 
freeze policy).

So I'd prepare a release for the changes 3 and 4 in a separate branch, 
upload that to unstable and try to get it into testing. Does that sound 
reasonable?

Cheers,
Martin