Hi Brian, If Michael sets up a 1.0.0 milestone on trac, then we'll just close tickets when they are fixed. What you did was actually right.
With regard to the dive_1.as bug we should open a trac ticket for this. We don't seem to use dive_1 in the linux x86_64 code. So I think this issue only affects the Windows side. Certainly we should fix this in the mpir-0.9.0 branch too. When I get a chance I'll issue mpir-0.9.1 with this fix. Normally this would be trivial, but as this will be the first service release, I need to do some work on my script so that issuing service releases is trivial. I also have to remember how to change the version numbers throughout MPIR. They appear in numerous places, including the documentation. Eventually I'll figure out how to write a script sophisticated enough to change all the version numbers automatically. Bill. 2009/2/27 Cactus <rieman...@googlemail.com>: > > > > On Feb 27, 5:12 pm, mabshoff <michael.absh...@mathematik.uni- > dortmund.de> wrote: >> On Feb 27, 9:07 am, Bill Hart <goodwillh...@googlemail.com> wrote: >> >> > Hi Brian, >> >> Hi Bill, >> >> > 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. >> >> I would actually do it the same way Brian suggests to do it and indeed >> that is the way we do it in Sage. If you want to see all tickets >> closed against a milestone there is something like >> >> http://trac.mpir.org/mpir_trac/query?status=closed&group=resolution&m... >> >> if you want to 0.9 milestone for example. We should create a 1.0 >> milestone (I can do that if no one else beats me to it) and assign >> tickets against that milestone. >> >> > 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. >> >> +1 >> >> > Bill. >> >> Cheers, >> >> Michael > > HI Guys > > I'll do it whichever way you folk decide. > > To be honest, I haven't ever used TRAC before so I just did what > seemed obvious, that is, complete the task and close it (i.e. it is > no longer a task!). I assumed that it would allow closed tickets to > be looked at against a release. > > In porting my assembler code to Core2 I discovered an obscure bug that > has been in my GMP assembler code for several years (it will only fail > very rarely, which is why I hadn't picked it up before now). > > I have corrected this in the trunk (it is in dive_1.asm) - should I > also correct this in the 0.9.0 branch? > > How should I report this - in TRAC or on this list? > > Brian > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
