Subject: Re: [Gnu-arch-users] Re: File naming conventions
From: Zenaan Harkness <zen@cashpoolcomps.com>
To: arch <gnu-arch-users@gnu.org>
In-Reply-To: <871xfi2gck.fsf@tleepslib.sk.tsukuba.ac.jp>
References: <20041019060152.GC18852@wisq.net>
	<1098311382.11967.35.camel@nemesis.xlii.org>
	<1098313564.5336.29.camel@whiskas.cashpoolcomps.com>
	<vpqmzyhhrhi.fsf@ecrins.imag.fr>
	<1098319598.5336.46.camel@whiskas.cashpoolcomps.com>
	<20041021123218.GA30989@fencepost>
	<1098398014.5336.118.camel@whiskas.cashpoolcomps.com>
	<BF588F2C-23C1-11D9-86E4-000393CFE6B8@spy.net>
	<buo7jpjk21o.fsf@mctpc71.ucom.lsi.nec.co.jp>
	<200410252034.i9PKYK4b066494@xl2.seyza.com>
	<20041025225439.GB19336@fencepost>
	<200410272159.i9RLxInD074896@xl2.seyza.com>
	<874qkf3r0f.fsf@tleepslib.sk.tsukuba.ac.jp>
	<1099007564.26442.36.camel@localhost.localdomain>
	<871xfi2gck.fsf@tleepslib.sk.tsukuba.ac.jp>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1099081700.26442.130.camel@localhost.localdomain>
Mime-Version: 1.0
Date: Sat, 30 Oct 2004 06:28:20 +1000
Precedence: list
Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Status: RO
Content-Length: 2736
Lines: 64
>     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?

No you should not include Linus sucks as project lead, because he _has_
explained on _numerous_ occasions the coding style and patch submission
style that _works_ (small, logically separate patches, post early, post
often, send through already trusted 'lieutenants' when the project got
big enough, etc, etc). Now, I'm not saying he never dropped a patch, but
_he's not saying that either_. This is the point of integrity - being
honest about what you did, and what's clearly working or not.

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

I cannot comment because I am totally unfamiliar with this developer and
community.

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

At a certain size, I'd agree. And some types of formalism can be useful
and beneficial.

If someone had to guarantee that they'd _look_ at patches after some set
of "successful" patches, perhaps they were working with relatively
insecure people who needed a formal mechanism to provide them with that
feeling of security; or perhaps the lead guy/developer needed the
formalism as a crutch for his own lack of self discipline.

I'm just guessing here of course.

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

I stand by my original statement. I am suspicious of a "10 good patches
and I promise to review your next patches" promise - to me that is
indicative of other issues; but if 10-patches-promise is the easy way
for those people to solve those problems, good for them and I'm glad it
works for them...

I haven't actually read Tom's "process" formalization document, but from
reading the comments on this list, it sounds like a different kind of
beast than this 10-patches thing you're talking about.


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/