gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: File naming conventions


From: Stephen J. Turnbull
Subject: Re: [Gnu-arch-users] Re: File naming conventions
Date: Fri, 29 Oct 2004 15:22:51 +0900
User-agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.5 (chayote, linux)

>>>>> "Zenaan" == Zenaan Harkness <address@hidden> writes:

    Zenaan> This is merely formalising what happens anyway - this is
    Zenaan> the community way (build up of trust).

No, it is not.  Yes, MvL's promise is a way to build a certain kind of
trust.  But this is a kind of trust that Arch has lacked, and most
projects lack.  This lack of trust is _currently_ an issue in arch, as
evidenced by the number of otherwise supportive people who have been
quite insistent about wanting to know what will be the process for
integrating patches accepted by James for the aborted 1.2.2 into 1.3.

My understanding is that it does not "happen anyway" very often,
although when it does the project is likely to be very successful.

    Zenaan> For example, as integrator/ project lead, Tom would either
    Zenaan> limit his ability to knock back bad patches from people if
    Zenaan> he promised that after 10 approved patches, he'd always
    Zenaan> pull them, or alternatively might be way too stringent due
    Zenaan> to fear of losing the ability to reject. Why go through
    Zenaan> all that?

What are you talking about?  The promise is to _look_ at the patch.
MvL himself says it's only worthwhile for patches that you value
highly but seem to be falling through the cracks (rather than being
deliberately dropped on the floor á là Linus).

Nor is it about the history of the contributor's own patches---it's
about what he does to help _other_ people's patches move through the
process, whether they ultimately succeed or fail.

    Zenaan> People who are committed will engender trust naturally.

Walter Landry is a counterexample.  James Blackwell is a
counterexample.  Both highly committed, both fired because Tom didn't
trust them to do things the way Tom would do them, with high enough
accuracy.  That's what Tom says (as I understand him, although he uses
different words with a somewhat different slant), and that's the way I
read the public record, too.

    Zenaan> And good project leads are good at working with people to
    Zenaan>   - explain why patches are no good
    Zenaan>   - recommend changes
    Zenaan>   - constructively encourage
    Zenaan>   - confer privileges to those who earn them.

Sounds a lot like GvR, I admit, but should I conclude Linus sucks as a
project lead, then, because he only does the last?  And interestingly,
it is a Python developer, in a project which already has a strong
culture of cooperative review, who feels the need to supplement custom
with a formal process.

    Zenaan> I'm not arguing outright that a formalism is
    Zenaan> inappropriate, just that I would personally view it as
    Zenaan> possibly problematic in ways...

Absence of formalism is _probably_ problematic.  We see this over and
over in free software.  I don't know of any FLOSS projects that have
strangled themselves with red tape (although admittedly I've heard of
quite a few in government and industry).

That's not to say that all projects need as much formalism as they can
get.  But I think that this particular formalism would be useful in
the context of Arch today.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]