>From: Eugene V. Lyubimkin <[EMAIL PROTECTED]> > 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 ( | [EMAIL PROTECTED] PGP F6B23DE0 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 2477\___\_|_/DC21 03A0 5D61 985B <-PGP-> F2BE 6526 ABD2 F6B2\_|_/___/3DE0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
