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&milestone=mpir-0.9
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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
