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

[Thomas Lord]

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

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

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.   As
it became clearer where the baz folks were going I concentrated more on
developing external funding of my own (which failed but not without a
few promising-looking starts including two small contracts) and on 
technical strategies to get past the "rush job" nature of the codebase
given that I'd pretty much have to do that alone.   The latter part
concluded with revc which, for all its charms, is de facto a "day late
and a buck short".

My turn for back-handed complements: You in particular lost my attention
because I wasn't worried about you.   You carved out long-term projects
for yourself, displayed far above average competence, don't come across
to me as one of the "kids".... I presumed we'd have plenty of time
to rendezvous later.   I was sad that you shifted focus to baz but
didn't see that (and still don't) as any great loss because you seem
reasonably self directed and I figured that you'd eventually either 
produce compelling results or refute a couple of interesting, hard-to-
evaluate design ideas in the trying.   Either way, incorporating the
results of your effort back into the mainline would be a small task
compared to projects you undertook.   If baz gave you a convenient
environment to work, regardless of whatever larger complaints I might
have about it, more power to you.

Where you're not quite fair is that I did voice my skepticism to you
about your approaches to both caching and back-building.   I did 
point at alternative strategies for both.   I didn't dwell on that
skepticism or "work you" to change course because between your maturity
and my lack of absolute certainty about the issues I didn't see any
proper basis on which to do so -- or need.


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

There's a middle road there that I tried to take.  You hadn't yet
produced results I found compelling so I didn't merge.  I hadn't
convinced myself that you wouldn't, so I didn't want to interfere.

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

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.

The way I see it, "leadership" in the FOSS community is celebrated
in terms of who can attract the most followers, more than anything
else.   By that metric, the bazfolk have me beat hands down.  Looking
around at the facts on the ground, the systems software and applications
we've wound up with, the attitudes, beliefs and expectations of 
volunteers, the products offered by the big companies --- 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.

Ultimately, if pressed, I would say that leadership is something
that sometimes *happens* to people, not something people do.
As individuals, the most we can *do* is to be prepared, principled,
and unselfish when and if the time comes.

Highlights from the tech talk:

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

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.

It might have made sense to look at tweaking the changeset mechanisms
to eliminate the reversibility issues you ran into although, 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).

> > Hardly unusable although perhaps slightly unexpected results.
> 
> Yes, unusable.  To make it usable, you need to issue tla
> set-tree-version $FOO.

You have an odd definition of "unusable".


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

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.


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

I misspoke then, slightly, on an issue that is well known.

I should have said something more like "either have copyright
assurance paperwork filed in accordance with standard FSF 
practice or are rejected because they do not".   I believe that
the FSF allows for alternatives to assignment but you'd have to
ask them for the details.   I believe that even when making 
assignments, the author can reserve rights to separately 
license the same code.

-t