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

[Thomas Lord]

Aaron,

Let's start with your conclusion, such as it is, and then move on to
your specific issues:


> 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.


Thanks, I suppose, for the backhanded complement.   I make no claim
to be a fountain of brilliant ideas.

As for my qualities as a maintainer, I challenge you to find one other
maintainer who has failed as gracefully or more (or succeeded) under
similar constraints.  Based on feedback, I'm absolutely certain I've
helped educate some young hackers in ways that have served them well
professionally.

One most note that you yourself have dedicated considerable effort 
to elaborating, with a few thousand lines of code, systems consisting
of several 10-thousand lines of code that I have maintained over the
years.   If you are bent out of shape because I have not been quick
to adopt some of your contributions which I considered problematic,
perhaps you can refrain from drawing conclusions about my skills
too quickly from that, given the opportunities my work has afforded 
you.

I'm not certain, anymore, about what a "good maintainer" is but I'm
pretty damn sure I'm not a "shitty" one, thank you very much.

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

I don't particularly want Arch back and I think your narrative there
runs contrary to history.   I certainly would refuse any opportunity
to resurrect the project in anything close to its earlier forms.

> 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.

Similarly, he has expressed sorrow to me.  "You don't deserve this," 
he said recently.   Sentiment is sentiment and actions are actions --
it rests, in part, with him to debug the disconnect between his choices
and stated intentions.
 
At any rate, let's turn to tech:

> 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.

That seems a rather odd description of the code in question.  We
are talking about talloc, right?  The "hierarchical, reference counted
memory pool system with destructors"?

http://samba.org/ftp/unpacked/samba4/source/lib/talloc/talloc_guide.txt



> 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.

I have never claimed that tla is anything other than what it is: a 
skilled and effective rush-job.   As for why your code failed, I really
can't speak to that.

> 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.

The semantics of dopatch don't preclude sticking file in directories
that don't exist --- it simply creates the needed directories.  I've
never seen any problems rebuilding even very old revisions using tla.
In some cases, this has meant making sure that new code is robust
against bugs in old code, which I did to protect arch controlled data.

No doubt my effort has been imperfect but I'm certain you are
exaggerating badly.


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

Hardly unusable although perhaps slightly unexpected results.  Yes,
Arch has not made a priority of protecting software developers from 
doing dumb things with their revision control system -- it is very
literal in interpreting commands given to it.

> Like, for example, the problems with mixed versions.

You are referring to an explicitly not recommended usage pattern
which, confronted with, tla at least behaves in a simple way.

> 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.

I'm not certain what specifically you are referring to although I do
recall fixing some bugs in that general area.

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

Similarly.  

> 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?

What about it?  If I suggested you stay the hell away from this and
that it was on the basis of your work in other areas.

> How about that new submission scheme you proposed?  The one that
> seemed to be designed to deny credit to any contributors?  

You are being quite goofy.   The scheme included a patch-log pruning
scheme but that has nothing to do with denying credit -- it had only
to do with not bothering to carry around unneeded metadata and with
expecting patch submitters to prepare clean, isolated patches.

> And they had to sign away their copyright?

No, they had to provide written assurance to the FSF that their
changes were free and clear.   Assigning copyright to the FSF is
an easy way to do that but not the only option.


> 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.

I've little doubt I did neglect a patch in that area that covered a 
relatively uncommon case.


I suspect you mostly have your panties in a bind because I was not 
especially eager to merge your back-builder work and generally thought
your approach to caching was broken.   I think I was clear all along
that your back-builder work was an interesting experiment but not 
obviously worth it (and, since revc, I'm certain it was not worth it).
I think I was clear all along that I thought your approach to caching
was just plain wrong (too much bloat for too little payoff, all based
on a messy model).

-t