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

[Aaron Bentley]

Thomas Lord wrote:
> On Thu, 2005-09-08 at 03:27 -0400, Aaron Bentley wrote:

> That's reasonably fair.
> 
> How that happened, and this isn't meant as an excuse, just a post
> mortem analysis:
> 
> I placed an ultimately losing bet on where to spend time once it was
> clear that there was far from enough time to everything desirable.

I would say the period between Jan 2004 and Oct 2004 had the most
influence on my opinions.  That was before Arch 2.0, but after the 1.2.x
train wreck, and Furth.

> My turn for back-handed complements:
(snip)
Thanks.

> I presumed we'd have plenty of time
> to rendezvous later.

I was motivated to make tla easier, faster, and more correct.  There was
probably some vanity in there too.  In any case, it did matter to me
that you took such a long time.

> Where you're not quite fair is that I did voice my skepticism to you
> about your approaches to both caching and back-building.

What I recall about the backbuilder pretty much matches what I see in
the list archive.  When I had completed the major work, I asked you to
have a look at it, you said you would (but that you were recovering from
illness), and as far as I know, you never did.

What I remember about the cache was that we had a good discussion about
how to make it better, and then suddenly, you dropped it, before I had a
clear idea what you wanted.

>>I think you're a smart guy with poor leadership skills.
> 
> 
> I don't mean to be defensive about my "leadership skills" but I would
> like to be clear that I'm not too impressed with how that phrase is
> tossed around in the FOSS community.
...
> I'm not too
> comfortable with the essentially cult-of-personality metric of 
> leadership.
> 
> Leadership shouldn't be viewed as a popularity contest or as a
> goal in and of itself.

Sure.  In the context of a Free Software project, I'd say a good leader
ensures that the project makes the best use of the resources it has.
Sometimes, the leader will be the project's only useful resource, and so
they should work on the code.  When there are other useful contributors,
  the leader should spend some time ensuring the submitted patches are
high-quality, some time ensuring contributors have the resources they
need (e.g. APIs, documentation), some time merging the patches, some
time coding, some time mapping out future directions.  Proportions will
vary by project, of course.

> Ultimately, if pressed, I would say that leadership is something
> that sometimes *happens* to people, not something people do.

I was referring to the act of leading, not the position of being a
leader.  Ah, English.  How it complicates communication!

>>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.  
> 
> 
> Ah.  Hence why the "backbuilder guy" would flip out about that.

Guilty as charged.

However, I do hope you got my point that one way is better than two.
Especially if the second way is so rare that the naive observer might
not realize it is there at all.  My feeling is that exact patching
should be as strict as possible, to ensure data integrity.

I think if almost all changesets are reversible, then users will assume
that all changesets are reversible, and that will lead to errors.

> I've tried to get across in the past and will give it one more go
> that the fundamental constraint of 1.x's delta-compressed format
> is to preserve forward patching -- each revision is signed, sealed,
> and delivered as whole-tree diffs from its immediate ancestor.  
> Everything beyond that -- merging, backbuilding, etc -- is just 
> cake.

Fair enough.

> ultimately,
> it seems like the simpler way forward is to blow off that kind of 
> delta-compression entirely (ala git, revc, and (if you say so) baz-ng).

Yeah, bazaar-ng adopted git-like storage before git existed.

>>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.
> 
> 
> In revc (Arch 2.0), archive identity is completely eliminated from 
> the namespace.   You are talking about fixing bugs around the archive
> namespace but I went ahead and entirely eliminated the cross-cutting
> code in which those bugs reside.

Yes, bazaar-ng too.  What baz did was they eliminated the use of
registered names entirely.  You can register multiple locations for a
given official name, but if you want to refer to a particular location,
you use its URL.  Amusingly, baz supports write-through commits as a
side-effect of those changes.

> I believe that even when making 
> assignments, the author can reserve rights to separately 
> license the same code.

Yes.  My understanding is that the FSF retains ownership of the code,
but licenses it to the author.

Aaron

-- 
Aaron Bentley
Director of Technology
Panometrics, Inc.