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
-~----------~----~----~----~------~----~------~--~---

Reply via email to