This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Setting milestones on PRs for bugs already fixed
- From: "Giovanni Bajo" <giovannibajo at libero dot it>
- To: "Richard Earnshaw" <rearnsha at gcc dot gnu dot org>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Wed, 12 May 2004 12:27:19 +0200
- Subject: Re: Setting milestones on PRs for bugs already fixed
- References: <1084355357.12936.18.camel@pc960.cambridge.arm.com>
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.
Well, there was no cvs-commit message to Bugzilla bound to that PR anyway.
Whoever fixed it didn't include the PR number in the ChangeLog. Even if we
(bugmasters) try to watch closely the CVS activity, we are not supposed to know
which PR each patch fixes, if any. And I think that closing the bug should be
up to the maintainer who committed the patch, even if we always double check.
> 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.
>
> 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.
>
> What to do? My slight bias would be towards the second option, but
> I've no really strong preference.
My suggestion is to go for the former. First, it's correct and consistent.
Second, there is no "freezed" release note for the bugs fixed in 3.4.0, because
there were too many, so we just have a link to a bugzilla query that shows all
the bugs, and I know for sure that both Andrew Pinski and I have adjusted
milestones for bugs in that list even after the release(1). Third, even if
there was a fixed bug list in the release note, I guess it could get updated at
any time. People can still double check if they need to.
If you reckon the bug is really important, I guess it could be added to the
3.4.1 release notes anyway, categorized under "Fixed already in 3.4.0, but not
reported as such" or similar. Whichever way we choose, I would strongly rather
Bugzilla to be consistent with what really happened.
Giovanni Bajo
(1) The original list contained more than 900 bugs, it's kind of hard to get it
completely right.