notes from gcc summit maintance BOF

[Benjamin Kosnik <bkoz at redhat dot com>]

The following are the notes I took during the discussion at the GCC
summit on Monday, May 26th. These notes might strike people as
oddly-arranged, but I tried to do my best. If people in attendance feel
as if I forgot something, or misrepresented something, or could express
something in a clearer manner, please suggest improvements and or
clarifications.

-benjamin


----------

need periodic meeting where long range planning / future directions discussed

  dedicated mailing list (gcc-process? gcc-futures?)
  (split up mailing list to lower volume lists?)

identify small issues that can be resolved
	
  configure/build
		
    have to take care of automake/autoconf issues, almost critical
    now. gcc is using ancient versions of each. In six months or so we
    will be completely screwed. Need a transition plan.

    can we go single directory at a time? instead of making everything
    work at once?  have to be able to do this incrementally?

    in repository must be something that works. update scripts must be
    able to get working build for people who don't care

    if file generated under wrong version, config/build fails and
    tells you what is wrong

    who will approve this patch?

    how long will this take?

    do we need a branch to do this stuff?
    alexandre, eric christopher, zack, daniel j., phil edwards, benjamin

    do we do all target library configuration stuff at once, and then
    use it for all target libraries.
		
    mistake made was not planning for transition to new autotools

    WHAT TO DO WITH REQUIRED VERSION of make

      - do nothing, have things undocumented and unexpectedly broken.

      - pick one, put it in the CVS repository or configure check
        bails if not found?

      - specific one, GNU make 3.79.1

    WHAT TO DO WITH REQUIRED VERSION of shell

      - is this stuff solved in new autoconf?

    WHAT TO DO WITH source/build sameness

      - configure kills
			
      - new autoconf/automake updates solves?
		
  planning changes to FE/BE (creeping interface-itis) 
  (making interface, modularity)

  documentation

    full documentation of all internal gcc macros

    adding explanation to code comments versus ChangeLogs and patch emails
    coding standards, discussion say
      + rationale, conclusion at a level of locality where it matters
      - not blow by blow of what is bad, trade-offs
		
    doxygen, can it help us give basic information ie, what does this
    function do, what are the inputs outputs for every function?
    Should doxygen style be set?

    formats
      - one internals manual
      - one generated sources manual
      - how to combine high-level internals with the sources documentation
		

  bugs
      
      how to help people triage the incoming bugs. All agree Wolfgang
      et. al. have made a huge difference: how to help them?

      auto verification of bugs, ie tool to scan bugzilla database and
      find open issues, verify it's still an issue with current mainline

      
  patch process

    - making bootstrap through make check faster
		
    - first pass?

      issues formalized (style, coding guidelines)
			
      patch queue (can we use bugzilla? Chris Faylor and D. Berlin
      need to (keeps things, nag maintainers, put in a "bounty" field
      in bugzilla?)

      need both submitter and maintainer fields for bug priority

    - second pass? patch server, auto testing of patches

    - third pass? more maintainers to approve check-ins?? 		

  making things friendlier for new developers 

    (documentation, beginner projects, automation, cross compiling)
    automation of regression testers

  maintainership

    more people who can approve patches

  testing

    interface between outstanding bugs and testsuite results: which is
    indicative of release quality?

    putting regressions into testsuite??

    making testing faster

    what fails on what platforms is unknown and often unclear. Can the
    existing tests be ranked for priority or severity?
		

RESOLVED to gcc-announce@gnu.org

1) test cases corresponding to bugs are a good thing (where to put
   them is unresolved)

2) doxygen style guide for gcc functions should be explored.  (Would
   like to avoid incomplete transition and partial implementation of
   this.)

3) automake can be upgraded incrementally on a per-directory basis,
   but not autoconf.

4) require GNU make 3.79.1, leave decision to put in tree or download
   as independent situation?

5) list of all tools and versions required to build done by Kaveh.