Re: Two volunteers needed: New scheduler and aliasing code

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

I'd like to first renew the call for volunteers, since nobody has yet
stepped forward to do the work with either of these changes.

    Unfortunately, the sources are not getting closer, because both gcc2
    and egcs are continuing to be developed. 

The fact they are both being developed does not mean that the sources
are either necessarily diverging or converging.  I hope the latter is
the case and intend to aim towards making it the case.  I suspect once
we get organized, we'll find that only 2-4 changes per year need to go
to EGCS first.

    This means that if you want a common CVS tree, it should happen ASAP,
    or it will only be harder to do in the future. 

I disagree since the steps of "catching up" are mostly manual. 

    I believe that doing a common CVS tree sooner rather than later will
    actually facilitate the process of bringing the sources closer, since
    you basically have to conduct a merge operation, and it's much easier
    to do this with CVS support than manually.

No, I don't see that at all.  The way I understand things, merges can
only be done automatically if the change is moved verbatum.  Even for
small changes that's not that common since, historically, most changes
I receive need some sort of minor editing before installation and if I
even have to change one character, I gain nothing from the merge
capability.

For a situation like this, where what's needed is to extract a large
set of diffs and work with them, I don't see anything but the most trivial
time savings in having a common tree.

Basically, automated (or semi-automated) merging works best when the
underlying sources are closest, and that's what I went to try to do
first.

But there's another issue: having the capability to do autonmated
merging seriously hurts quality control because the relative cost of
doing minor edits when installing changes is so much higher that
there's a very large temptation not to do it.  And making those minor
changes are usually what's very important in keeping the quality of
the code high.

I suspect whether or not having a common repository makes sense or not
depends strongly on what kinds of procedures Jeff and I end up
employing as we work towards keeping the sources closer.  We're still
discussing those.

    Cygnus is not only on the west coast; last time I checked, Jeff Law's
    in Utah, Michael Meissner is in Cambridge near the FSF.  So two of the
    four folks listed as having "Blanket Write Privs." in the egcs
    MAINTAINERS file are not on the West Coast.  Furthermore, some of the
    folks who have write-after-approval access to the egcs CVS tree are in
    Europe.  They seem to be managing OK.  So I believe this to be a
    non-issue.

Since it seems like I'm the only one concerned about speed, it sounds like
if we do have a common repository, it should be at the FSF, right? ;-)