Setting milestones on PRs for bugs already fixed

Richard Earnshaw
Thu May 13 09:34:00 GMT 2004

On Wed, 2004-05-12 at 20:15, Joe Buck wrote:
> On Wed, May 12, 2004 at 10:49:17AM +0100, Richard Earnshaw wrote:
> > The night before last I closed PR target6434.  This bug was finally
> > fixed in the 3.4 release, but nobody updated the PR to reflect this.
> > 
> > That brings up a question.  What should the milestone be set to?
> > 
> > If I set it to 3.4.0 then that will correctly reflect the release that
> > fixed the problem, but that is already out now, so the closure of this
> > bug will never appear in any release notes.
> In the special case of 3.4.0, I did not prepare an explicit release notes
> list; there is just a Bugzilla query.  That was a one-time solution
> because there were over 900 bugs, and my usual practice of organizing the
> fixed bugs and modifying titles to make them clearer didn't seem feasible.
> So what that means is that the link from gcc-3.4/changes.html will find
> your report if you set the target for 3.4.0.

So it does.  Cool.  I'll leave it pointing at 3.4.0 then.

As a side note it would be nice if the selected fields could be tuned
for this report: the only interesting ones are bug # and summary. 
Target might be useful as well, but host very rarely is.  I don't know
if bugzilla can be tuned in this way, but I'd be very surprised if it

> > If I set it to 3.4.1 then the closure will appear in the 3.4.1 release
> > notes, but it might be slightly misleading as to when the problem was
> > really resolved.
> My suggestion as Release Notes Guy is as follows: for the 3.4.0 case only,
> if you find that anything was missed, go ahead and set the target for
> 3.4.0.  In the future (since I plan to go back to my previous releases
> notes procedure), set the target milestone appropriately *and* send me
> mail, and I'll do a patch tot he release notes.

While auto-extracting on the fly is sometimes a little slow, I wouldn't
be upset if we always did it that way, provided it displayed useful


More information about the Gcc mailing list