Re: [Gnu-arch-users] preparing to stress test tla with linux-2.5

[Tom Lord]

    > From: Tupshin Harper <address@hidden>


    >> From: Tom lord

    >> I'll add you to the list of people [....] to whom I should, in
    >> some sense, be advocating breaking the kernel up into a
    >> multi-project config. 

    > Can you explain your thoughts on this? Do you mean (for example) that 
    > high level kernel subdirectories would be different projects? Is there 
    > any rationale for this besides arch performance? How would changesets 
    > that span multiple projects work?


Lot's of little rationales rather than just one big one.  Here's some:

Arch performance is one reason -- but the relevence to arch
performance is relvent to plenty of other things as well.  In general,
when streaming the source in a "unit of management" through some
process takes so long that it's uncomfortable, maybe it's time to
reduce the "unit of management" size.  (and, again, the upcoming
inode-signature optimization will greatly reduce the number of
circumstances under which arch wants to read the whole tree and yadda
yadda yadda.  (But no such optimization is forseen for, say, grep,
agrep notwithstanding.))

Another reason to partition the source when it gets that large is to
make it harder to make the parts _that_ interdependent.  It's a way to
encourage better engineering.

Changesets spanning multiple trees?  That's part of what configs are
for.  Committing a top-level, config-containing directory is
effectively an atomic commit across multiple sub-projects.

-t