Re: source mgt....[_HAS_ gcc relevance]

[Tom Lord <lord at emf dot net>]

       with GNAT, we let everyone within ACT, which is quite a diverse
       set of folks about 35 in all, change anything in the mainline,
       but we guarantee the monotonic properly (I agree this is
       crucial) by enforcing fairly strenuous requirements on anyone
       doing a change. [....]

Thanks for the report. 

A lot of the thinking behind arch is to scale up and simplify adopting
practices such as you describe so that they are applied by default to
pretty much all of the free software (and "open source") projects in
the world.  With your 35, you have social pressures and the power of
the employer to enforce restrictions like "run the tests before
committing to mainline" -- but wouldn't it be nice if that were
automated: so a developer could hit the "try to test and merge" button
before going home for the night, coming back in the morning to either
a commit email or a list of test failures -- and if you _didn't_ have
to write all your own tools for that automation because they were just
there already, such that setting up a new project with these
properties was as easy as creating a project on Savannah currently is
(or, easier :).


    > With good tools, the release manager can ultimately be
    > replaced by shell scripts.

    I don't believe that, based on our experience where we have
    elaborate scripts that try to automate everything, but you still
    need a release manager to coordinate activities and check that
    everything is working as expected.

Yeah, I said it badly.  Observing gcc, Mark makes lots of judgment
calls and sets focus and picks dates and things like that.  I only
meant that a lot of the mechanical source and repository manipulation
chores can be far better automated than foisting them off onto poor
'ol Zack :)

I have a question about ACT:  How much value do you place in "clean
changesets" and how much would you if they were easier to manipulate?

Feature branches of GCC get smooshed into big merges on mainline, and
I'm wondering if my feeling that keeping changes independent is
shared by others.  Maybe this applies more to the kernel, where
long-lived distribution forks regularly differ in their choices of
changes applied.

It's an interesting question for a rev ctl implementor because, if
maintaining clean changesets is a big deal, then I think you want some
high-level features to help maintain them over time.  For example, if
one change appears on mainline, then months later, a fix related to
that change appears -- then you want to help cherry-pickers associate
those two and combine them.  Another example: under some
circumstances, you want to recognize textually distinct merges that do
nothing more than combine equal sets of changes as, in some sense,
equivalent (as in, I did that same merge as him but in my own way --
even thought I don't have _his_ patch for that merge, don't treat my
tree as if it were missing that patch.)

Second paragraph says:

       A lot of the thinking behind arch is to scale up practices such
       as you describe so that they are applied by default to pretty
       much all of the free software (and "open source") projects in
       the world.

That's part of why I'm pretty frustrated.  I think that is "obviously"
doable and "obviously" generates an (admittedly hard to measure in
conventional ways) ROI on R&D investment in arch.  Nobody seems to
know how to do that in industry, though -- or even how to consider the
correctness of my assessment.  People know how to do things like "buy
Rational".

-t