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

[Zenaan Harkness]

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