Re: gcc development schedule [Re: sharing libcpp between GDB andGCC]

[Andreas Jaeger <aj at suse dot de>]

Tom Lord <lord@emf.net> writes:

>        I agree.  I think the releases should be an 8-month cycle rather
>        than a 6-month cycle.  In other words, 4 months for destabilizing
>        changes.
>
> Given the distributed and opportunistic nature of development,
> wouldn't a phaseless approach be worth considering?  Ultimately
> lower cost for all participants?  Certainly put GCC in the position
> of being better able to make near-instant "emergency releases" to correct
> defects that escape up-front testing?  Certainly avoid snafus like
> Red Hat experienced a little while back?
>
> By "phaseless" I mean an approach in which there is a permanently,
> continuously QA'd trunk with a high barrier for changes.  Presumably
> along with that, a collection of advanced trunks on which related
> destabilizing changes are collected and worked-out.  This is sometimes
> called "hierarchical software management" (where the hierarchy is of
> lines-of-development, not people).
>
> The path from here to there would seem to be one of simply
> beefing up the infrastructure with better automation, and 
> better testing tools.

I think GCC is going already slowly in this direction, the barrier is
higher than it was, a year or two ago:

- we have automatic testers and benchmarks so that the trunk is build
  and tested on a daily basis on different platforms
- we have a policy of patch reversion for patches that are too broken
- we have a policy that patches should have testcases with them for
  regression testing

I agree that it's better to analyze the effects of a patch directly
after it went in (or even better before) instead of some months
later.  

Further enhancing the testing infrastructure is one objective that I'd
like to see and where I've worked on already,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj