Sorry this answer took so long. First the usual disclaimer: I am not a release team member.
On Sunday 17 August 2008, Kurt B. Kaiser wrote: > > Lenny is frozen, the release team will never accept so many > > changes to go into Lenny. > I understand your feeling about this. However, I think you might > be overly pessimistic, because the changes aren't as extreme as > they might seem to be when looking at the changelog. I still think that the release team will not accept this update. After all, they have to review the diff. And 31 files changed, 605 insertions(+), 219 deletions(-) is not easily reviewed, even if ~ 250 lines are documentation. But you can ask the release team yourself, if you don't believe me. > I began with changes to pass the standard Debian flags to configure > and to build in the source tree instead of in a subdir. I did this > so the Makefiles would be available when running maintainer-clean > to remove the auto-generated files resulting from autoconf. This > produces a much cleaner .diff.gz, which now only contains entries > from .../debian and its subdirectories, which is a goal when dpatch > is used. This step was verified with interdiff. This is exatcly the kind of change that should be deferred until lenny+1, IMHO. > Fixing #481755 and #483868 involved one word changes to fix > important regressions. I think that inspecting the changes will > show them to be non-problematic. These should be included then. > Updating to compatibility level 7 and Standards 3.8.0 introduced no > additional changes. If there are no changes necessary then it might be ok. But changing debhelper compatibility level is something I would avoid so close to the release unless you need the change. > Adding amavis to the trusted users is a one word change to a config > file, and non-disruptive by inspection. No problem here. > There were several changes to improve the documentation, and that's > allowable per the Lenny freeze guidelines. Yes. > Now, the webfrontend: Previously, we had a non-functional demo > VirtualHost fragment. I moved it to its correct location in > /etc/dspam/ and modified it to be served on localhost only, with a > simplified login using htpasswd. I also moved other files that the > user might be expected to customize. Having a working website > following installation should help those users who were having > difficulty getting started with the webfrontend configuration. I > tested this by running the website. This also looks like something that should better be deferred. > There was an issue with upgrading etch: the /usr/share/dspam dir > had some symlinks which were causing upgrade errors. This is a > serious bug, at least, and had to be fixed. Yes. > One of the Lenny goals is to pass the piuparts test. The > webfrontend was not purging correcty, and I made some changes to > fix that. The changes were most cleanly accomplished by putting > the webfrontend config files under ucf control. A less intrusive way would have been better, I think. > There were no changes to the core of dspam or the webfrontend, so I > don't think any of the above could be considered disruptive. But all in all, it's quite a lot of change and there is plenty opportunity to introduce new bugs. This is something that should be avoided if possible. Cheers, Stefan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
