Bug#474947: the state of Bug#474947
>From: Eugene V. Lyubimkin <jackyf.devel@gmail.com>
> A Mennucc wrote:
> > IMHO one way to decide if to accept a patch during the freeze is to
> > see how large and "important" it is. Does anybody have an example
> > patch, or a description of what code changes would be necessary?
> I had a look on this bug and, thus seems I have. I don't understand why
> Elliott ignored my previous 2 mails about it. So, I am repeating my humble
> look here. Reasons for not touching this bug anymore before Lenny release are:
I ignored nothing. This does not mean I will come to the same conclusion.
> - this patch reduces apt speed (not serious though, as I see) on most
> operations with the cache;
I guess I should ask, do you have an less issues less relevant waiting in
the wings? While more speed is good, that is worthless if it is badly
broken.
> - fix requires a big patch (small part of it was written by me, see #474947
> thread);
> - this patch have to change internals of apt;
> - this patch can break apt API and ABI (don't checked);
> - this patch definitely requires thorough review and testing;
Here it is a matter of the weightings. The flipside is without this
fixed:
- Almost certainly a significant number of users will run into this
issue during the lifetime of Lenny (the history is 5-10 bugs/year; plus
an unknown and likely large number of people who do not report it since
they see it has already been reported and therefore presume work has
already begun on fixing it).
- This complicates debugging, as it escalates otherwise harmless issues
to major severity (see #400768; while certainly an otherwise unrelated
bug, if the MMap issue wasn't present, this bug would never have caused
any problems).
- It is quite likely that upon upgrading to a version of Debian after
Lenny, APT will again break due to this issue and again have to include
a major warning in the release notes.
- As far as actual impact of the change we still do not know. Despite
knowing about the first problem for at least 5 years (#178623 is the
oldest report I have found), and knowing that it was still very
definitely an issue for a minimum of nearly 2 years (#400768); we still
do not have anything but rough guestimates. It might be that this is the
time your estimate is wildly wrong, but we do not know since no patch has
ever been tried. Why not try this in experimental? Then we would have
real experience to judge how much work it will take to fix.
> I don't think this would be acceptable by release team.
Too a point I think I can summarize your position as: It is too dangerous
to fix this in Lenny.
Correspondingly I can summarize my position as: It is too dangerous NOT
to fix in Lenny.
There is no clearly right answer here. The issue is which will damage
Debian more; delaying the release, or releasing with another serious
issue?
> Elliott, reason for this bug is apt architecture. Do you think we can easily
> change architecture of the core package at freeze stage?
I have made no such claims. I am merely stating that this is a serious
bug. Severe enough to seriously consider delaying the release. This is
what the release team gets to decide, which is worse (neither option is
good)?
Yet, since you've got an initial patch, why not put that out in
experimental? It might be found that fixing it isn't anywhere near as bad
as you thought. Even though it changes the API/ABI, if no one has ever
touched that field, the impact on other packages will be zero. Perhaps
the release team will decide it is worth delaying the release, in which
case a head start in testing will be of great value. Perhaps some other
issue will force a delay of the release, in which case the extra time
might allow sufficient testing.
--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\BS ( | EHeM@gremlin.m5p.com PGP F6B23DE0 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
2477\___\_|_/DC21 03A0 5D61 985B <-PGP-> F2BE 6526 ABD2 F6B2\_|_/___/3DE0
Reply to: