Bug#766249: iceweasel: wheezy force upgraded to 31.2.0esr-2~deb7u1

[Carsten Schoenert]

Am 22.10.2014 um 18:33 schrieb William Herrin:
>> Wanna bet what Red Hat does? Spoiler alert: the same thing
>> https://www.redhat.com/archives/rhsa-announce/2014-October/msg00026.html
> 
> Mike, you summarize my complaint: with iceweasel you've done the same
> lousy job at versioning that Red Hat does.

We do not making any versioning, we take the upstream version and append
a Debian appendix. Red Hat is making exactly the same (like Arch,
Ubuntu, Gentoo, ...). So nothing has do be done here "better".

> You can do better. To come close to meeting the Debian patch
> guidelines, you must do better.

No! We do nothing on the versioning! We do nothing more than provide a
actual, more bugfixed version for the current stable release of Debian.
That's simple and that's all.

>> Reality is that the choice is between not shipping a web browser, or
>> shipping one that's secure.
> 
> Nonsense. I offered three credible alternatives to the current practice
> for iceweasel in yesterday's email none of which requires significant
> additional effort from you.

Let's take a look:

> 1. Introduce an iceweasel32 package and obsolete the old iceweasel 
> package at the point where you're no longer able to provide security 
> updates to it. The obsoleted package won't be removed until the
> sysadmin decides to remove it.

This means we should skip the ESR version 31 with the security fixes and
put a current devel version into stable? Possible, but seriously, why
should we do that? That's one step more than the current solution, take
the current ESR version into stable security.
And one thing more you seems to forget, the DD's and DM's can't do any
directly big security support for upstream packages! We are depending
here on the work on upstream. But of course we are staying in contact
with many upstream authors.

Have you take a look into the source? Really? If so so I think you
wouldn't say something as you did.

> 2. Offer a high-priority dialog at install time if the version being 
> replaced is enough older to have compatibility problems, advising
> that the version being installed is known to be incompatible. Offer
> an "abort upgrade" option which will fail out of the package install.

No, we do a security update. So there is nothing to do so. If there is
something to tell we have a NEWS file for things like this. And no,
there there no known issues with the update. Mike already has written
something depending an the new UI design.

> 3. Package firefox 32 and the previous Wheezy firefoxes in the same 
> bundle. On first run for a user following the update, prompt for
> which version to execute advising that versions older than current
> are known to have security flaws.

This is "none of which requires significant additional effort from you"?
Do you have tried to package a Iceweasel package by yourself? Do you
know how much work is needed for doing this to get a release which is
building on all platforms?

And once again NO! We use only the ESR version for stable-security as we
did for the last quite 2 years! Doesn't matter if you care or not, no
one is push you to use the stable version of a Debian release. If you
want, please come up with patches, you are invited to work on any
package inside Debian!

>> It's impossible to ship a secure browser
>> that stays at the same major version anymore[1].
> 
> Agreed. Nevertheless, your conclusion above does not follow from this
> fact. There are better ways to handle the problem that blithely blowing
> away the users' configuration, including better ways at the same level
> of effort. Open your mind.

Sorry, this isn't true! Don't come up with this without facts! I haven't
seen any bug on this that a user is loosing any configuration depending
on upgrading from Iceweasel 24 to 31.
So I would say it's up to to open your mind, not surprisingly you are
alone with your thinking.

-- 
Regards
Carsten