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

[Philippe Moutarlier]

Hey guys, 

should we rename this list something like "Tom Lord's Last Stand" ? 

It has been funny for few days but is getting old quickly.

Tom , I don't know you at all. But you sure sound pretty obnoxious.
Sometimes when everybody say you're bad, the best quality would be to
say "OK. I'll try to improve". This IS what a good leader would expect
from its troups.

Philippe

  




On Thu, 2005-09-08 at 08:49, Thomas Lord wrote:
> 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
> 
> 
> 
> 
> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnu-arch-users
> 
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/
>