From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5187 invoked by alias); 20 Jan 2004 03:27:51 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 5179 invoked from network); 20 Jan 2004 03:27:51 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 20 Jan 2004 03:27:51 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0K3Rjl00415; Mon, 19 Jan 2004 22:27:45 -0500 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0K3Rja27001; Mon, 19 Jan 2004 22:27:45 -0500 Received: from dnovillo.cipe.redhat.com (dnovillo.cipe.redhat.com [10.0.0.106]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id i0K3RgXd014650; Mon, 19 Jan 2004 22:27:43 -0500 Subject: Re: [RFC] Contributing tree-ssa to mainline From: Diego Novillo To: Geert Bosch Cc: Daniel Berlin , Joe Buck , "gcc@gcc.gnu.org" , Steven Bosscher , Richard Kenner In-Reply-To: <8DCDA992-4AF6-11D8-AE43-000A959A128E@gnat.com> References: <10401170324.AA15949@vlsi1.ultra.nyu.edu> <20040119153026.A21678@synopsys.com> <476C5192-4AD9-11D8-8DB8-000A95DA505C@dberlin.org> <8DCDA992-4AF6-11D8-AE43-000A959A128E@gnat.com> Content-Type: text/plain Organization: Red Hat Canada Message-Id: <1074569238.25137.206.camel@frodo.toronto.redhat.com> Mime-Version: 1.0 Date: Tue, 20 Jan 2004 03:27:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004-01/txt/msg01439.txt.bz2 On Mon, 2004-01-19 at 22:13, Geert Bosch wrote: > On Jan 19, 2004, at 18:43, Daniel Berlin wrote: > > Anyway, It would be more productive if we were to try to concentrate > > on a specific set of merge criteria for tree-ssa, than continue to > > discuss the benefits or disadvantages of it (since it seems clear the > > overwhelming number of people think it has great benefit already) > > The single biggest issue is documentation. > We try to keep it fairly detailed and complete. The API documentation is published nightly, created directly from the source code comments. As with any evolving piece of code, I will not guarantee that the documentation is complete, but it should not be hard to derive .texi documentation out of it. > As you say, there are thirty > optimization passes. That means that there should be thirty descriptions > of these passes > Fewer, actually. Some passes are repeated more than once. > So I would like to push for strict standards for documentation. > All new code must meet the documentation standards *before* merging. > Also, any old code that may be affected by the changes needs to be > reviewed and stale comments need to be updated. In my opinion everything > else is secondary. > This goes again to my request for peer review. All the API documentation is available online. You don't need to even check-out the branch. Follow the links from http://gcc.gnu.org/projects/tree-ssa/ You will find high-level design documents and API documentation. We need bugzilla reports that point out specific bits that are missing. I have created PR13756 to begin tracking documentation issues. Feel free to add what you think is missing. Thanks. Diego.