[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] details is details, not punctuation

From: Aaron Bentley
Subject: Re: [Gnu-arch-users] details is details, not punctuation
Date: Wed, 07 Sep 2005 22:43:46 -0400
User-agent: Debian Thunderbird 1.0.2 (X11/20050331)

Ah, I was keeping the high ground, biting my tongue, but what the hell.
 It's only emails.  They'll just be archived forever and come back to
haunt me when I least expect it.

Thomas Lord wrote:

> Arch was forked because I declined an offer for employment from 
> Canonical because I found the details of the offer to be 
> obnoxious.

That's not the impression I had at the Bazaar code sprint last November.
 The impression I had was that tla was forked because:

1. Canonical was trying to use tla everywhere, but they found it hard to use
2. They didn't believe they could improve matters with you as a maintainer.

I completely agree with them.  That's why I wrote aba, and, later, Fai.
 Because when it comes to usability, I believe you are damage that must
be routed around.

> I've pointed out starting places for comparing changes made to
> baz to tla.   I've far from exhausted my reservoir of comparisons
> and have chosen only the easiest ones I could think of to start
> at.

Those comparisons have shown that Canonical has different priorities
from yours.

That alternate memory allocation scheme you so roundly dismissed looks
to them like a very useful thing.  By using a second stack object, they
were able to ensure that resources such as memory and temporary files
were cleaned up properly, without requiring the programmers to be
superheroes.  It was a framework on which they could implement
exceptions, so that they could provide better error messages.

Your code is not as excellent as you seem to think.  I wrote an
alternate changeset implementation, and made it as strict as I could.
Then I used it to build the Arch mainline from beginning to end, and it
was a carnival of horrors.  I had to implement several kinds of conflict
handling in order to apply it successfully.  There aren't supposed to be
conflicts.  It's supposed to be exact patching.

But even the latest versions of tla, to the best of my knowlege, still
produce non-reversible changesets-- they stick patchlogs in directories
that don't exist.  You write buggy code, and you don't fix it.

Like, for example, the way you could "tla get $FOO-MIRROR", and produce
an unusable tree.

Like, for example, the problems with mixed versions.

Like, for example, the botched invariants in the inventory code from
doing signed sorts of filenames, and expecting them to have the same
order as unsigned sorts.

Like, for example, the way changeset application does directory removes
by the equivalent of rm -rf, which can delete precious files or source

Or how about the time I suggested that star-merge should maybe warn
people if a criss-cross merge had already been committed, and you told
me to stay the hell away from star-merge?

How about that new submission scheme you proposed?  The one that seemed
to be designed to deny credit to any contributors?  And they had to sign
away their copyright?  The one that was awkward, and technically
impossible, but I had to post star-merge error messages at you in IRC
before you'd admit it?

One of my "favourites" is the fact that changeset application over
renamed directories was reported broken in April 2004, (on Bug Goo, and
the mailing list) stayed broken, and yet you were claiming it was fully
supported in March 2005.

Really, Tom, you cannot claim the high ground on technical issues.  Arch
was brilliant.  tla was not.

>   Is it the case, as I suspect, that your notion of a "good job"
> as maintainer would have been to just pass-thru whatever came
> down the pipeline?

No, but it would have been nice if you'd either merged the back-builder,
or else told me something was wrong with it.  Just doing nothing after
I'd put in considerable effort to improve performance was totally

>  Have you been studying the code, the history
> of changes, etc.?  Do you presume me to have infinite time and
> resources to just quietly cleanup the turds they were dropping?

No.  It appeared to me that you said nothing, did nothing, and then
later, would wave your hands about code quality, without providing
useful critiques or constructive advice.

By that point, we were all pretty used to you not merging stuff, and
inventing new programming languages in your spare time.  So we weren't
optimistic that you would ever merge anything.

> Oh my goodness, you really don't read very carefully do you.  Over the
> years and even in these threads I have confessed to many mistakes and
> worked hard to correct them.

I won't deny you've improved.  You used to make claims that boiled down
to "Any sufficiently advanced revision control system is
indistinguishable from Arch".  When we first asked your opinion about
bazaar-ng, you were vague and dismissive.  Then, when revc came out, we
saw that you'd realized that Arch 1.0 wasn't the be-all and end-all.

Revc solved many of the same problems that bazaar-ng solved, sometimes
in the same way.  If it had come out first, and if you weren't the
project maintainer, I might well be working on it now.

> If anything, I am to be criticized for too much capitulation and an 
> insufficiently aggressive resistance to the baz crew long past the point
> at which it should have been obvious where they were going.

Where they were going was incrementally improving the codebase to
support a more revc-like model.  The baz team was the 'evolution' team.
   Bazaar-ng was the 'revolution' team.

Me, Martin and John Meinel have been the main contributors to bazaar-ng
so far.  Canonical put most of its resources into the C codebase up to
this August, and the plan was always to have to have baz fully support
bazaar-ng's model.  You can see some of the planning that was done
earlier this year at sites like this:

It was at the UDU conference that I told Robert Collins that I'd soon
switch from working on baz to working on bzr.  He seemed rather sad
about that, because he was committed to developing the baz codebase.

Your accusation that Canonical has been shitting on the codebase is bunk.
Your accusation that Canonical always planned to jettison the codebase
is bunk.
Therefore, your accusation that Canonical has been shitting on the
codebase because they planned to jettison it is also bunk.

Stop whining about them stealing your project.  You abandoned the
project.  They adopted it.  Then you wanted it back.

They didn't steal me as a contributor; you lost me first.  Of course,
it's quite possible you don't consider that a loss, so maybe it's good
that I stopped pestering you, and went to work elsewhere, where people
are glad of my contributions.  Nicer for everyone that way.


P.S. Really.  You're a shitty maintainer.  I hope you find a situation
where you can be the visionary, and come up with brilliant ideas, but
not be required to maintain the resulting projects.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]