Re: Python extension commands in git - request for policy change
- From
Eric S. Raymond <esr@thyrsus.com>
- Date
- Nov 25, 2012, 17:32 UTC
- 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>