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

[Aaron Bentley]

Thomas Lord wrote:

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

Oh, I don't know if a postscript qualifies as a conclusion.  I'm much
happier with "Therefore, your accusation that Canonical has been
shitting on the codebase because they planned to jettison it is also
bunk" as a conclusion.  It's got a "Therefore" in it, which I always
like to see in conclusions.

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

I believe that you have a lot of great ideas just as strongly as I
believe you're a bad project maintainer.

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

James Blackwell, when he was maintaining the 1.2.x series, before he was
employed by Canonical.

> Based on feedback, I'm absolutely certain I've
> helped educate some young hackers in ways that have served them well
> professionally.

Personally, I've gotten a lot out my relationship with you, but that's
been our discussions, not what I learned from your behavior as a maintainer.

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

That's not what I'm bent out of shape about.  If you feel that
particular changes are inappropriate, it's your duty as a maintainer to
reject them.  You never actually did reject them.

It would have been helpful if you had, because I might have learned
something about what kinds of changes were appropriate, and how to do
things better next time.  There's even a chance that you were rejecting
the changes due to a misunderstanding of them, which I could have
cleared up.

But I can't do anything better if I don't know something's wrong.

Alternatively, if you considered that my work was such that I was
unlikely to produce merge-worthy code, the kind thing to do would have
been to tell me so.  I would have gone away and done something else.  I
certainly wouldn't have kept showering you with garbage patches.

> perhaps you can refrain from drawing conclusions about my skills
> too quickly from that, given the opportunities my work has afforded 
> you.

I am certainly grateful for that, and I have learned a lot from Arch.

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

Opinions will always vary on this, but I am quite secure in mine.  The
fact that tla stagnated during 2004 with no commits for months at a
time, despite there being known bugs, and several eager contributors in
the community, suggests that the project leader was not effective.

>>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 did say 'wanted'.  I was speaking about the work that started with
Matthew Dempsky.  It seemed to coincide with the increasing popularity
of Bazaar.

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

I said something similar to Robert Collins and James Blackwell.  I said
"It's his fault, but he doesn't deserve it."  I think you're a smart guy
with poor leadership skills.  I don't see any inconsistency there.

> At any rate, let's turn to tech:
> 
> 
>>That alternate memory allocation scheme 
...
>>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

Yes, that's the one.  The destructors being a fairly critical part of that.

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

Oh, my code didn't fail.  It encountered conflicts attempting to apply
the changesets, because the changesets were inconsistent with reality.

The ArchConflictHandler, which was intended for use with so-called
"exact patching" had to
1. permit mismatches between the changeset old-file text and the tree text
2. permit mismatches between the changeset old-permissions and the tree
3. avoid creating directories that already existed
4. handle directory removes when the directories contained files
5. handle attempts to patch missing files
6. handle attempts to remove missing files

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

Right.  This is not reversible, because when you apply the changeset in
reverse, the directory is not removed, so you aren't returned to the
initial state.  It is also inconsistent, because directory adds are
almost always are explicitly described in changesets.  It seems that the
create-missing behaviour adds mostly-useless complexity.

> I've
> never seen any problems rebuilding even very old revisions using tla.

That doesn't contradict the fact that the changesets are not reversible.

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

Perhaps I kept a log around.  I'll have to see.

>>Like, for example, the way you could "tla get $FOO-MIRROR", and
>>produce an unusable tree.
> 
> 
> Hardly unusable although perhaps slightly unexpected results.

Yes, unusable.  To make it usable, you need to issue tla
set-tree-version $FOO.

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

The flaw runs deeper than that.  Pretty much all of tla doesn't
distinguish between registered names and official names.  Registered
names are commonly used where official names should be.  I know this
from my work on writethrough commits.

Since the resource at $FOO-MIRROR is $FOO, when you get a revision from
$FOO-MIRROR, the only sensible thing to set the tree-version to is $FOO.

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

It's not very obviously warned against.  It is easy to do by accident.
It cannot be reversed once done.  Supporting it causes additional
complexity in the model.  It would be simpler to just not do it.

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

tla would fail with a botched invariant when the inventory contained
files with high-bit characters, because listdir returned files in
signed-sorted order, but you treated them as though they were in
unsigned-sorted order.

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

This is the line:
rmrf_file (tmp_shuffled_dirs_root);

This approach is unnecessarily cavalier.  You can simply remove
directories in reverse order by pathname length.

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

star-merge had enough information to know that it could not correctly
pick a merge base.  Yet it picked a merge base anyway.  This caused
severe usability problems.

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

That was certainly how it seemed.  That's what the patchlogs represented
to me.

> -- it had only
> to do with not bothering to carry around unneeded metadata

It was not unneeded.  star-merge required it to work properly.

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

On 25/10/04, you said:
> However, going forward, I hope to reach a state where all
> non-"trivial" contributions (i.e., those meritting copyright
> protection) are either assigned or are rejected because they have not
> been assigned.


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

It was one of many bugs I encountered, reported, didn't feel qualified
to fix, and never was fixed.  Just like you quickly learn with CVS to
never rename a file, Arch teaches you to never rename a directory, or
change a file to a sylink.

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

No, see above.  Clear rejection, especially if explained, was fine with
me, and I never asked you to merge the cache.

>  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 never got a clear impression of that from you.  I was hoping that you
would merge it for a long time.

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

Yeah, and I felt that you were too familiar with local mirrors to really
grasp their shortcomings, and understand why something else was needed.

What bloat though?  Surely not disk space; revc would take up far more.
 You mean the CachedArchive wrapper?  Can't have been more than a few
hundred lines.

Aaron