From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6418 invoked by alias); 26 Oct 2009 02:01:21 -0000 Received: (qmail 6100 invoked by uid 22791); 26 Oct 2009 02:01:20 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_FAIL X-Spam-Check-By: sourceware.org Received: from mx20.gnu.org (HELO mx20.gnu.org) (199.232.41.8) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 26 Oct 2009 02:01:16 +0000 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N2EtW-0008BF-8Z for gcc@gcc.gnu.org; Sun, 25 Oct 2009 22:01:14 -0400 Received: (qmail 27183 invoked from network); 26 Oct 2009 02:01:10 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 26 Oct 2009 02:01:10 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.69) (envelope-from ) id 1N2EtR-0005mD-FQ; Mon, 26 Oct 2009 02:01:09 +0000 Date: Mon, 26 Oct 2009 07:11:00 -0000 From: "Joseph S. Myers" To: Basile STARYNKEVITCH cc: GCC Mailing List Subject: Re: when (not) use bugzilla for GCC? In-Reply-To: <4AE4998D.7040608@starynkevitch.net> Message-ID: References: <4AE4998D.7040608@starynkevitch.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-detected-operating-system: by mx20.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-10/txt/msg00515.txt.bz2 On Sun, 25 Oct 2009, Basile STARYNKEVITCH wrote: > I cannot understand when should I use or not bugzilla. More precisely, I have > several examples of "bugs" but I didn't use bugzilla for them If something is a bug in trunk then you should report it, but do not submit reports that do not contain sufficient information to convince the reader that there is a bug. For example, a report should not rely on source files on a third-party website, installed system headers, or on the hypothetical correctness of some unreduced code (if you are claiming wrong code, reduce it to a single function or a minimal set of functions). For development branches, it's up to the branch maintainer. If they wish to use Bugzilla for bugs in them, they should add appropriate versions so the bugs can be accurately reported as bugs against the branch. > 2. a couple of weeks ago, I submitted a patch regarding gengtype for plugins > (the patch was greatly improved by Rafael Espindola espindola@google.com) and > the patch did correct a bug. > http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00379.html > but I never bothered registering it (since making the initial patch was easier > than reporting a bug). This is also the case of > http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00809.html > (fatal error when failing to register a pass) If you want a regression to be tracked as such, it needs a Bugzilla entry, even if there is also a patch submission. Any bug with a patch can be filed if desired, but do not use Bugzilla as a patch submission mechanism; send patches to gcc-patches and use the "patch URL" field in the bugs. Ping patches on gcc-patches weekly until they are reviewed. If you attach a patch in progress to Bugzilla, make clear that it is a work in progress and that a final version will be submitted to gcc-patches. If you stop working on a bug, do not leave yourself assigned to it; ASSIGNED should only be for bugs where you are genuinely working on them. > 3. On the MELT branch, I regularily find bugs & correct them, and it did > happen that someone registered a MELT bug on the bugzilla; I did correct it > but AFAIR was not permitted to close the bug. Sometimes I am sad of not being > able to report MELT bugs on bugzilla and to close them when I feel I have > covered them. Log in to Bugzilla with your gcc.gnu.org address to get access to close bugs, add versions and milestones, etc. -- Joseph S. Myers joseph@codesourcery.com