On 4/27/06, Don Brown <[EMAIL PROTECTED]> wrote: > I like that, and if they don't close it by the release, the release manager > will close it.
I don't understand why we should set this up so every ticket has to be closed twice. The tickets are already subject to peer-review by the PMC and all the subscribers to dev@ (or issues@). We have nightly builds going out every day that reflect the changes made by the tickets. If the problem is fixed, then the release testing should prove that it is fixed. I don't believe that we should be turing the release manager into some type of clerical assistant or gatekeeper for the rest of us. If the RM wants to review the tickets that have been closed since the last relesae, that's fine. But I would suggest that we not try to dump any additional responsibility on this role. It's a hard enough job as it is. My suggestion would be that whoever applies the patch should also supply a test that proves the issue is resolved, and then closes the ticket as fixed, until shown otherwise. It doesn't have to be a fancy test. In the case of a taglib, it could just be a use case in the taglib exercise application. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
