In-Reply-To=<[EMAIL PROTECTED]> Hi Security Team,
a while ago you refused to support mantis in a stable release. That was prior the Etch release, quiet exactly one year ago. After all I understood that this time. However, three months ago I've closed the RC bug that you opened in the BTS and asked you to reopen it if there are any objections. No response. I also asked debian-release to unblock mantis so it could enter testing (and so I could provide a backport for Etch, cause some users requested it) this time, but got no reply. I didn't know what was the reason for neither a rejection, nor an acceptal, but a recent IRC chat with Mark 'HE' Brockschmidt and Andreas Barth gave clarification. They told me that security team is expected to either say "We are willing to provide security support for mantis in a stable release" or at least "We are taking back the statement re no security support for mantis" in order to get mantis unblocked. So what I would like to ask you is to repeatedly check if your earlier statements are still true. What you said when the topic came up: a) Mantis had a bad security record (21 distinct vulnerabilities between 2004 and 2006) b) Upstream kept information hidden in inaccessible bugs c) Mantis has no significant user base Here are my statements about this arguments: a) In the last year there was only one security record, which was fixed quickly. Besides the given situation when I adopted the package the situation seems as if it became better. b) I can't really say what has been in the past. But there was a discussion on this with upstream last year, which was held between Victor Boctor (as the current upstream project leader), Gianluca Sforna (who is responsible for the Fedora Core packages of mantis) and me. We agreed on some things, notable most that bugs are not hidden anymore. Since then security issues has been tracked publicly in the projects bug tracker in a category called 'security'. Additional to this Gianluca is part of the development team and cares a lot about that what might be of interest to packagers of mantis. This includes porting security fixes (which are normally made in the development branch) to older upstream releases. I must say that upstream is *very* responsive _and_ helpful. Having a packager in the development team to care for distributors interests was a good idea as well -- and afair it was the idea of upstream. So given this I cannot agree with a statement that means that upstream is not corporating very well. I'd even say that the work with this particular upstream is one of the best I yet had in my work as a Debian contributor. c) Making assumptions on mantis user base is probably not so easy, given that mantis has been in a *very* bad state over the last years in Debian, because it must have been unmaintained for a longer time when I adopted it, without it beeing orphaned. Also not having mantis in Etch nor having a backport for it does not better this situation. Besides that there is a list of users on the upstream site [1] and user activity on the mantis mailinglists is high, so I came to the conclusion that the reason for the bad popcon stats is not mantis itself but the state of mantis in Debian. I could be wrong, though. Please give a clear statement if your arguments from the past are still true. Thanks and best Regards Patrick Schoenfeld Mantis Maintainer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
