Re: A minor adjustment to the development plan

Re: A minor adjustment to the development plan

[Richard Kenner]

    I tried to relay this intent by using the wording above; do you have any
    suggestions how to make it more clear?

I would just be very explicit: "The branch to be merged must successfully
pass the regression tests with the exception that it is permitted to fail
tests that were added within the last week."  The exception avoids the
"moving target" problem I was concerned about.

Re: A minor adjustment to the development plan

[Gerald Pfeifer]

On Mon, 22 Sep 2003, Richard Kenner wrote:
>  + * No regressions caused by the changes on the branch are logged against
>  +   the GCC bugtracking system or have been brought to the attention of
>  +   the branch maintainer(s) in some other way.
> My feeling is that there's a difference when a branch is merged in because of
> the size of the work being merged.  Certainly we don't want a branch to
> introduce a lot of problems, but branch merging only occurs at a stage in the
> development cycle when we are willing to tolerate some instability.

I agree.

> My concern is that both the branch and the mainline will be moving targets
> and it may not be feasible to have a single point in time when all known
> regressions have been fixed.

What I had in mind were those cases where the branch (before the merge)
already contains regressions which have been known for several weeks,
that is, which are not related to the merger per se.

This was the case for the objective-c branch (where the problem was fixed
before the merge) and is the case for tree-ssa, for example, and I think
that such regressions should be fixed before proceeding with the merge.

I tried to relay this intent by using the wording above; do you have any
suggestions how to make it more clear?

Gerald
-- 
Gerald Pfeifer (Jerry)   gerald@pfeifer.com   http://www.pfeifer.com/gerald/

Re: A minor adjustment to the development plan

[Richard Kenner]

    I suggest to extend this by

    + * No regressions caused by the changes on the branch are logged against
    +   the GCC bugtracking system or have been brought to the attention of
    +   the branch maintainer(s) in some other way.

    Rationale: a regression we know about is a regression we know about,
    whether it occurs in the testsuite or not, and per our development plan
    patches which cause known regressions are not acceptable.

My feeling is that there's a difference when a branch is merged in because of
the size of the work being merged.  Certainly we don't want a branch to
introduce a lot of problems, but branch merging only occurs at a stage in the
development cycle when we are willing to tolerate some instability.

My concern is that both the branch and the mainline will be moving targets
and it may not be feasible to have a single point in time when all known
regressions have been fixed.  Obviously, you don't want to merge if things
can't bootstrap or there are a large number of regressions, but it may be
better to "take the hit" and introduce a few regressions than to keep
delaying the merge until it's perfect: if the number of regressions is small
enough, it's going to be far easier to fix them in the merged mainline than
to do so in the branch, while trying to keep it up to date with development
in the mainline.

A minor adjustment to the development plan

[Gerald Pfeifer]

I plan to raise the following on the steering committee, but before I
do so, I'd like to get some feedback from this list (even though it's
actually more of a clarification than a change).

In http://gcc.gnu.org/develop.html we currently have the following:

| Changes may be merged from a development branch only after:
|
| * They meet the standards for any other check-in. For example, the
|   code must be well-documented, and any user-visible changes, including
|   command-line options, should be documented in the manual.
| * The branch has been validated on three different targets, each
|   targeting a different microprocessor family. Validation should consist
|   of bootstrapping the compiler (unless that is impossible for the
|   microprocessor selected) and checking that there are no new regression
|   test failures. It is acceptable to use a simulator for validation;
|   the use of real hardware is not required.

I suggest to extend this by

+ * No regressions caused by the changes on the branch are logged against
+   the GCC bugtracking system or have been brought to the attention of
+   the branch maintainer(s) in some other way.

Rationale: a regression we know about is a regression we know about,
whether it occurs in the testsuite or not, and per our development plan
patches which cause known regressions are not acceptable.

Gerald