possible red flag for new C++ parser

[Tom Lord]

       The free software world is mostly over this hump, in that
       projects that are still being maintained fixed their code.
       That is, most of the breakage from "C++" that wasn't really C++
       at all, but just code that happened to compile with old g++
       versions, has been fixed.


That's good to know.  How do you know, by the way?  Has this been
measured?

To return to the orginal question on the matter of C++ breakage, your
assesment means that gathering up a lot of "real world" code for a
test suite should be tractable, after all. (As you say "Debian packages
requiring g++ would be a good collection".)


       [even if there's still a lot of broken not-quite-C++ code]:

       The problem will sort itself out, but it will take work.
       Fortunately, the work tends to distribute: maintainers of a
       particular free software package are the experts at fixing that
       package, or can figure out what to scream to the GCC team
       about.


No doubt -- I don't deny that.  It's just that, _if_ this is plausibly
a common problem, then I'd think it makes sense to do some sampling to
quantify it early, because if it's large, then while it's still being
"sorted out", people will still be reving platform distributions. 
If you're right, that most everything that matters has already been
fixed -- then fine.  So, again, how do you know?


        If we had some kind of automated build farm to build large
        bodies of code regularly and report on problems, that would be
        cool.  It would still be labor-intensive to set the thing up
        and to analyze results from it.

Do you think my guesstimate of a few man months is wide of the mark?
At least to get a measure of what happens when you throw the new
parser against, say, Debian?   A requirement for a few man-months of
concentrated effort on something a bit off-beat like making tests for
GCC is a kind of edge-case in the free software world:  even though
the labor requirements are smaller than many free software efforts,
it's not the kind of thing volunteers tend to sign up for in droves.

But to return to the _original_ original question:



    > And in any event, there's (ultimately, if the tools and
    > processes were better) no need to go through this kind of thing
    > on the trunk.

    Certainly there is.  If you don't test the trunk, the trunk will
    be broken.  You can't merge code, even perfectly working code,
    from muliple branches and expect that breakage due to interaction
    will never occur.

Do I understand you?:  you are saying "if the new parser sits on a
branch, the trunk will diverge from that branch.  While the parser is
being tested, the trunk will continue evolving.  Even if the parser
gets debugged on the branch, when you merge it to the trunk, that's a
whole new tree that's never been tested -- so new breakage will likely
ensue."


If I do understand you, then I say: "Not so.  You just keep `updating'
the branch to keep it current with the trunk.  Your branch keeps
looking like what the trunk will look like after the new parser is
merged in.  When you finally merge into the trunk, the resulting tree
looks just like the latest revision on your branch.  All that testing
you did on the branch applies perfectly to the new trunk." (e.g.,
http://regexps.srparish.net/tutorial/elementary-branches.html and
http://regexps.srparish.net/tutorial/development-branches.html).

-t