What do do regarding the freeze?

[Petter Reinholdtsen]

[Martin Steghöfer]
> Hi Petter!

Hi.

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

Totally understandable. :)

> 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?

Yes.

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

"invalid memory access" raise a red flag with me regarding security.
I have not looked at the code, but would like us to be very sure the
issue isn't remotely explorable before decide it isn't a security
issue.  If it is a security issue, the severity should be higher than
important, I believe.

> 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?

Sound good to me. :) It might also be possible to discuss it with the
release team and ask which changes they would accept into Jessie
during the freeze.  They might accept more fixes this early in the
freeze, but to be able to ask them I believe the patch reordering need
to be undone to allow them a fighting chance to review the real
changes.  But I do not really expect myself to have time to follow up
on this issue with the release managers, so for that to happen someone
else must take the lead. :)

-- 
Happy hacking
Petter Reinholdtsen