This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Some bug policies [Was: Bug Digest 5/24]


Dara Hazeghi <dhazeghi@yahoo.com> wrote:

> gcc-bugs. My worry is simply that gcc-bugs will become
> only a place where bug reports are discussed, and
> actual discussions of bugs (independent of bug
> reports) will be lost. I'm not certain if this was an
> original intent of the list, but that was my
> impression...

I don't think we want discussion of bugs in this list. A bug which is
discussed is lost until it's filed to Bugzilla. And besides, we are not
asking users to post their bugs in gcc-bugs. gcc-bugs is just a way to track
what's going on, people should file bugs to Bugzilla, and then discuss them
on the audit trail of the bug itself.

> Regarding the messages themselves, I'm not subscribed,
> so I stick to reading the archives.

Yes, but we still don't want the list to be flooded. If you feel that there
are a certain kind of "bug updates" that shouldn't need to be posted on
gcc-bugs, just raise the issue, we can fully configure which kind of mails
gcc-bugs gets.

> Hmm... I guess my primary concern is that bug reports
> with patches are ignored long enough that the patches
> themselves become irrelevant. I don't think this is a
> good way to do things.


Patches should be posted to gcc-patches, and then the message linked from
within the bug. gcc-patches is the only place where the reviewers look, and
where the patches can be approved. If a patch is only posted to the bug's
audit traild and never makes it to gcc-patches, it's almost impossible that
it will get a review.
So, if you find patches that were never reviewed in the bug's audit trail,
you could explain the author to post it to gcc-patches. Also, we could add a
keyword "patch-pending" for bugs whose patch was not reviewed yet (but I
kind of fear that reviewers are not going to query for it often...)

>> Yes. If you can veryify that a bug always existed on
>> 2.95 up 3.3, but it's
>> fixed in 3.4, you can close the bug. The right place
>> is on the main page:
>> GCC 3.3 branch is open for regression fixes only.

> Good point. I missed that. Umm, does going back to
> 2.95 mean testing one release per branch, or testing
> all of them? Ie, is 2.95.3, 3.0.4, 3.1.1, 3.2.3, and
> 3.3 sufficient? Thanks,

Yes, you usually want to check with the last dot release of each branch. Of
course, if a bug is reported against 3.2.1, and you cannot reproduce it with
3.2.3, you should check with 3.2.1 or 3.2.0 to see if you can reproduce it.
Closing a bug without being able to reproduce it is a risky move.

Giovanni Bajo


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]