Re: [Gnu-arch-users] quality, bazaar, arch, etc.

[Stephen J. Turnbull]

>>>>> "Thomas" == Thomas Lord <address@hidden> writes:

    Thomas> Stephen says:

    >> I'd still like to see some support [for the assertion that
    >> Bazaar is an engineering disaster], pretty please, with line
    >> numbers and lint warnings on top.

    Thomas> Assuming that you don't literally mean `lint(1)' that's a
    Thomas> valid enough request.

No, I'm taking a page from asuffield's book, and going to the other
extreme from what I perceived others to be doing.

    Thomas> 1) What difference will it make?  Is demand for an answer
    Thomas> to that question standing between me and
    Thomas> financial/economic recovery?

Not directly.  The SCM field right now is too crowded, and has somehow
missed the point that Arch and in a different way Darcs tried to make,
and I suppose other advanced SCMs that I don't know much about.
Details in a footnote.[1]  Bottom line: to make money in this market
segment is going to be very hard.  And I believe you do need to "make
thatmoney": to get out of your hole and do what you want at the same
time you need to get a business started---you do need that much control.

But hey, you've said any number of times that although SCM design is
fascinating, there are plenty of other things you could be doing, and
much of the time would rather be doing.  I don't know where, but I'm
sure that somebody somewhere has a pile of money they should spend for
what you can do for them.  As I've said to you many times before, IMO
you need to swallow hard, hold your nose, and learn marketing,
starting with Remedial Marketing 101: How to Suck Up to People Whose
Lives Would Be So Much Better If They'd Just Listen to You, and Give
Them What They Think They Want Instead.  If there's a benefit to you
in going through the whole thing, it's pointing in that direction.

    Thomas>    Instead, engineering is inherently multi-disciplinary
    Thomas> and pragmatic.

Grandmaw already knows how to suck eggs, thank you. :-)

    Thomas>    A complete analysis of the disaster would not look only
    Thomas> at the code (which has plenty of problems) but would also
    Thomas> look in detail at the community participation and would
    Thomas> "follow the money".  A complete analysis could easily
    Thomas> reach book length.

Make it sing, make it dance, and sell the book.  :-)

    Thomas> You are asking for a lot of labor to be spent to prove a
    Thomas> case that some credible sources already see quite plainly.

Jose Marchesi I don't know, he may be credible but not to me.  You and
Andrew I know and respect, but both of you have big blind spots around
marketing and human resource management.[2]  Both of you are capable
of convincing me, but your unsupported opinions are unreliable.  Who
else do you have in mind?

BTW, you don't need credible sources to see your case, you need
financial sources.  I'm probably not one (certainly not on the scale
to make a long-term difference), but I'm probably a pretty good
approximation to the way they think.  Or don't think, for that matter:
I'm likely to have many of the same blind spots, but I like to think
I'm a little more self-aware than your typical tycoon.

    Thomas> Why is it important to answer your request?

If I could explain that to you, you'd already know the answer.  :-)

More seriously, I don't know that it is.  Part of it is that I think
you're a little bit nuts on the subject and would like to be convinced
otherwise.  The other part is that for precisely that reason I may be
a good model to test strategies on.

    Thomas> You prbly do understand the code issues well enough to
    Thomas> think through some of the changes in default options and
    Thomas> implicit operations on yr own.

As you say, I could read diffs.  But I actually don't consider baz to
matter very much, not even very symptomatic of carelessness.  Fred
Brooks said "build one to throw away", and they did.  I'm far more
interested in what's happening with bzr, which no longer looks much
like Arch at all, and (based on the design notes, haven't read the
code) seems to have gone past YAGNI to IDUIT (I Didn't Use It Today)
as a criterion for removing interfaces.

Also, as you pointed out, the real issues here are manifold and
transcend "mere code".  (a) What important engineering goals got
slighted, how and (more important) why?  (b) How did the flows of
money, power, and other incentives get twisted to create a defective
process?  (c) Is the presumption of twistage in the wording of (a) and
(b) actually justified?  I think it was Fred Brooks again who said
that "every organization is doomed to produce architectures that
mirror its own structure", which I definitely agree with.  But it's
hard to map back from the product (which is static, in the end) to the
(dynamic) organizational process that produced.  Diffs aren't going to
help there, even to the extent of comparing tla and baz processes.

Does that need to be answered, here and now, more or less in public?
I don't know.  My feeling is that you need an attitude readjustment,
and answering those questions might either help you to do that, or
change my feeling and give me enough knowledge to do something more
helpful than be the Annoying Opposition.  Whether that matters enough
is something for you to judge.


Footnotes:
[1]  Darcs development has returned to its roots as a field of
abstract algebra with little relevance to day-to-day software
engineering, and Arch 1.x is in not much better shape, in the sense
that I can see ams's point that the UI of tla is pretty much fine as
it is---there's going to be incremental progress but where's the next
big step?  It's needed, heaven knows: it's still far too easy to find
topologies that wedge you badly with any of the current crop of SCM,
especially if you're trying to move from one to another.  And it's
still easy for novices to wedge themselves, even just in day to day
work---none of the SCMs have the kind of smarts that (human) Arch
virtuosos do.

As the bzr stuff shows, there are plenty of people even among those
attracted to Arch who really just want a better CVS.  I conjecture
that there are just too few people who can perform the necessary graph
tracing in their heads to support Arch as the artists use it.  Git is
_very_ interesting as an independent piece of the puzzle, but Linus
and his lieutenants can do the graph tracing, so git will remain at
the level of plumbing (with porcelain that, somehow, looks just like
CVS ;^) indefinitely.  Really, now, can't we just get past CVS? :-)

[2]  Quite possibly Andrew is just shucking us, but if so he's doing
you a disservice.


-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.