Re: Firefox and Sarge
On Tue, Aug 24, 2004 at 07:17:50PM -0700, Matt Zimmerman wrote:
>
> On the other hand, Mozilla has changed a great deal since woody, and it's
> often unclear whether a bug even applies to this ancient code, much less how
> to fix it, without a great deal of research. This makes it also a poor
> candidate for backporting.
>
> The conclusion is that Debian cannot, on its own, effectively support
> ancient releases of huge and complex software packages by either means.
>
That's exactly my tought. So what? Do not release these programs is against
interest of our users. Releasing them is against the future interest of
our users. Do you see the light? Security policy needs exceptions
to be considered on a per-case basis. Some programs need a decent
major upgrade, there is not a better solution. We could think to a sort of
'ports' (gooosh!) archive and keep those beast off stable under the
responsability of a new stable-ports-team. That could be proficient for a group
of apps which are now in 'beta' status for upstream, too. Well that's an idea.
Anyway, releasing a beta release in sarge is like searching soon problems for later.
> > But on a case by case basis, maybe a bit more this needs to happen, rather
> > than being bloody-minded about backporting security fixes where it's just
> > too much work.
>
> The assumption that backporting is more work is largely erroneous, when you
> consider both development and QA. The idea of backporting is to fix a bug
> while reducing the chance of regressions by introducing many other changes.
> By limiting the changes to specific areas of the code, the chance of
> regressions is reduced, and QA is simplified. In the common case, fixing a
> vulnerability by backporting is on the whole less work than attempting to
> provide a new upstream release with the same level of confidence.
>
Yes, but I cannot see any recent (within the last year and half) installation
of woody where users did not install a recent version of mozilla, instead
of the pre-1.0. So in some cases, secteam efforts are at least a waste of time.
In those cases that time would be better used in packaging a well-done major
upgrade. Users would be more satisfied, I think.
--
Francesco P. Lovergine
Reply to: