Re: [Gnu-arch-users] Re: fixing and extending "selected commit"

[Tom Lord]

    > From: Miles Bader <address@hidden>

    > > So, you know, if your development environment is _so_ out of scale
    > > with your tree that copying the tree is just too horrible to
    > > complicate:  then perhaps either your environment is far weaker than
    > > you need, or your tree is out of control.c

    > Well what do you want me to say?  Clearly trees like linux (or emacs)
    > are accepted by the general developer community as being `small enough'
    > for general use; if arch can't handle them, people will think `arch
    > sucks' rather than `my development style sucks.'  Me too, BTW; sometimes
    > there are pretty inescapable reasons to do things like tree-copying, but
    > well, not in this case.

    > Having a _way_ to do what's basically a `copy-as-if-committed-
    > respecting-limits' might be great for doing pre-commit testing or
    > whatever, maybe I'll even use it sometimes, but I think it's not
    > appropriate to make it the only way to do partial commits.

This all gets very "philosophical", in a way.  We should be at a party
sampling the most recent additions to a wine cellar and some third
guest could pipe in about how he compiles _his_ kernel from scratch in
under a minute....  so I'll just ramble a little bit:

>From the informal performance reports I've gotten, we're closing in
very fast on handling linux kernel size trees well enough to say
"that's good enough."  For some users, competently using arch, we
might even be there already.

But it's definately close to the edge.   And, interestingly, arch
would sharply reward a new degree of modularity: breaking up the tree
into a config, for example.   I find it a depressing conclusion to
believe that the kernel is permanently such a monolith that it can not
be so broken up in the name of greater modularity.

Nothing arch does to any tree is _absurdly_ heavyweight.  A few find
traversals.  A few copies.  A few link trees here and there.  That's
piddly foo.  It doesn't get much less than that.  Now, if those
operations are _so_ expensive on your tree that you feel pained and
resistent to doing them N+1 times per day --- that doesn't just mean
arch is the essense of the pain for you: it means that a lot of very
basic techniques are out of your reach.  Arch is the least of your
problems.  You're going to be a less effective programmer in this
situation regardless of whether or not you use arch.

What'd it take to make the kernel more modular?   Some Makefile
hacking, some config hacking, some "correctness preserving code
transformations", perhaps -- I'll do everything I can to make arch not
be the forcing function for those improvements -- but I won't pretend
for a minute that they aren't very worthwhile improvements.   Arch
/exemplifies/ the problems .... it doesn't /create/ them ... and
displaying the uniformity of the laws of math and physics across the
universe: arch rewards solving the underlying problems.

Restricted commits are a fine thing to work on.  They're a fine thing
to work on, as rwa has reminded us, because of their /semantics/.
That they may or may not be faster for this or that purpose?
Interesting -- but not a central concern.  That they may or may not be
more convenient in a given workflow?  Well, that part is interesting.

"Another goal of the arch project is to /help free software
development projects work better/" -- www.gnu.org/software/gnu-arch
-t