Having said that, if all tickets were assigned to a milestone, we could get away with closing tickets. But at present we have no mpir-1.0.0 milestone in the system. Of course then we would have to be careful to assign bug fixes such as the ones I just described, to no particular milestone before closing them, otherwise the release manager would have to try and figure out which tickets represented bug fixes from the previous release and which were bugs that have never been released.
Bill. On Feb 27, 5:07 pm, Bill Hart <goodwillh...@googlemail.com> wrote: > Hi Brian, > > I think it is much better if we don't close trac tickets until the > release is made. That way it is easy for someone writing the NEWS file > to see what has changed for this release. Instead simply prepend > [done] to the title of the ticket. > > There is one exception to this. That is when we are fixing bugs which > we created during that release cycle, i.e. bugs which don't occur in > an actual release. E.g. suppose Developer X breaks the build system > while implementing some new function and someone else notices and > opens a trac ticket. Then if the issue is resolved and determined to > have been caused during the release cycle, then we may as well close > the ticket, as the bug should never have been there in the first > place. > > Thanks for sorting out the windows code. That's awesome. > > Bill. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@googlegroups.com To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
