From: Eric S. Raymond <esr@thyrsus.com>
Date: Sun, 25 Nov 2012 17:32:29 GMT
Subject: Re: Python extension commands in git - request for policy change
Message-ID: <20121125173229.GA32394@thyrsus.com>
In-Reply-To: <CAMP44s1oRpm4QkhcbfAuxK8UTZnuSVfNhAQnmUd1xiwhwLEqGw@mail.gmail.com>

Felipe Contreras <felipe.contreras@gmail.com>:
> Seems sensible, but I don't know what "rejection" would actually mean.

Why is this mysterious?  We reject a patch when we don't choose to merge it.

> My "extensions" are on the way to the contrib area. Is the contrib
> area supposed to have different rules? I don't know.

I don't have a strong opinion about this.  I lean towards looser rules
for contrib because, among other things, it's a place for experiments
and we disclaim responsibility for maintaining it. But requiring 2.6
compatibility for Python scripts is not really onerous.

> Too late.

I'd be happy to help you out by auditing them for version dependencies.

> I don't see what this means in practical terms. People are going to
> write code in whatever language they want to write code in. How
> exactly are "we" going to "encourage" them not to do that is not
> entirely clear to me.

One way is by having clear guidelines for good practice that *include*
Python, and tell people exactly what the requirements are.

> Subcommands are also probably more efficient in c. And lets remember
> that most people use git through the *official* subcommands.

See my remarks on the 80-20 rule elsewhere in the thread.  Execessive
worship of "efficiency" is a great way to waste effort and pile up
hidden costs in maintainance problems.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>