This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [arch-users] [lord@emf.net: Re: gcc branches?]



       > I don't think that it is wise for gcc development to start
       > using Arch quite yet.

To be clear, neither do I.  However: the path from my last release to
a rock solid, fully deployed (for gcc or a similar project) 1.0 is
both easy to map out, and quite affordable relative to the overall
size of investment in (e.g.) GCC.  Moreover, it will pay a return not
just via GCC -- but via other projects as well.

I spent (quick guesstimate) about $75k out of pocket on `arch' R&D.
The design is accessible.  The bugs Walter mentions have simple
solutions: experiments have been done that prove this and, anyway, it
is pretty easy to figure out a priori just by looking at the
(relatively small) code.  The value of the design is apparent to
anyone who looks into it with care.  The need for `arch' and related
technology is apparent (and even crudely quantifiable) by reading the
gcc dev list for the past year or two.  I stand by my assessment that
"Y'all work to hard [on mundane, by-hand, fault-ridden process
issues]."

We have two, related I think, failures here.  One is a failure of free
software businesses to learn how to do this: to take the product of
strategic R&D and make tactical investments to bring it to market.
The other is the failure of development communities, such as gcc, to
be sufficiently reflective about their practices, to earnestly examine
proposed solutions like `arch', and to help make the case to the corps
that investment in this area is needed.

	> I would estimate that it will take another 5 months or so
	> for Arch to get to the point where I am comfortable
	> recommending it for general use (that is, to people who are
	> not interested in working on version control).

My standards and ambitions are a little bit higher than Walter's, I
think.  There are some open issues (such as formally specing a well
thought out change-set format) that are not being addressed by his
development efforts.  I think it is fair to say that some of the
changes being made in his branch violate what I consider to be
critical design principles.  It's also fair to say that I am obsessively
perfectionist about some things -- arch being one of them -- and 
the more traditional approach Walter has been taking has produced
some good insights.

"Marriage" of a small, funded team of arch developers to some target
project(s) like gcc is a natural way to proceed: it can ground the
final few laps around the rev ctl./process engineering theory track to
the very demanding demands of a very high quality team with a good
record of setting high process standards.  I wouldn't expect the 
GCC community to be easy-to-satisfy customers: the very opposite, and
usefully so.

The free software development communities all need to tighten up their
practices.  The GCC project stands out among the other projects as the
one that has the greatest clue in this area.  Let's build tools,
simplify your jobs, and make better practices easier for others to
adopt.

-t


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]