This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Closing PRs for 3.4.1
- From: "Giovanni Bajo" <giovannibajo at libero dot it>
- To: "Gabriel Dos Reis" <gdr at integrable-solutions dot net>
- Cc: <gcc-patches at gcc dot gnu dot org>,"Gerald Pfeifer" <gp at suse dot de>
- Date: Mon, 7 Jun 2004 13:08:50 +0200
- Subject: Re: Closing PRs for 3.4.1
- References: <40C22C5B.8080400@codesourcery.com><1bc201c44b6b$87f85800$444e2a97@bagio><m3aczhjrlf.fsf@uniton.integrable-solutions.net><1c9f01c44b7a$fb183ee0$444e2a97@bagio> <m3n03hia67.fsf@uniton.integrable-solutions.net>
Gabriel Dos Reis wrote:
>>> There is an agreement between Mark and I that he can retarget a
>>> regression present on gcc-3_3-branch and gcc-3_4-branch to the next
>>> release of 3.4.x, provided that he put me in the CC: and there is a
>>> notice to that effect. It would be helpful if you (bugmasters)
>>> apply that strategy too.
>>
>> Thank you for clarifying this. I'll try to remember to post a patch
>> for the website documentation about this policy.
Done thus. OK to commit?
Giovanni Bajo
Index: bugs/management.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/bugs/management.html,v
retrieving revision 1.23
diff -c -3 -p -r1.23 management.html
*** bugs/management.html 24 Jan 2004 10:13:57 -0000 1.23
--- bugs/management.html 7 Jun 2004 11:07:00 -0000
*************** marked as such. The summary line should
*** 205,212 ****
severity "<strong>critical</strong>" to bring it to attention. It may
be downgraded later if a defect is not important enough to justify
"critical" severity. In addition the target milestone should be set
! to the next release that needs fixing. The milestone can be changed
! by the release manager and his/her delegates.</p>
<p><strong>If a patch fixing a PR has been submitted</strong>, a link
to the message with the patch should be added to the PR, as well as the
--- 205,214 ----
severity "<strong>critical</strong>" to bring it to attention. It may
be downgraded later if a defect is not important enough to justify
"critical" severity. In addition the target milestone should be set
! to the next release of the newest active release branch that needs
! fixing (the rationale is that a patch will have to go to the newest
! release branch before any other release branch). The milestone can
! be changed by the release manager and his/her delegates.</p>
<p><strong>If a patch fixing a PR has been submitted</strong>, a link
to the message with the patch should be added to the PR, as well as the