develooper Front page | perl.perl5.porters | Postings from August 2011

"How A Bill Becomes Law" or "On getting changes into the Perl 5 core"

Thread Next
From:
Jesse Vincent
Date:
August 29, 2011 09:42
Subject:
"How A Bill Becomes Law" or "On getting changes into the Perl 5 core"
Message ID:
45DEC384-B470-4549-9E30-29BB8E7F5BD9@fsck.com
From time to time we've discussed what it takes to get a proposed change into Perl 5. In the course of a recent chat with Chip, I wrote out the following guidance. 

To a first approximation, it's a codification of what has already been the policy. It's my hope that by writing this down, we can slightly smooth out the "significant change" contribution process. I'd love feedback on this before a variant of it ends up in perlpolicy.pod. It is not my intent that this policy be applied to bug fixes or documentation improvements.

My current thinking is something along the lines of:

* With a written proposal for a significant core change, we can either reject it or say "maybe"
* With any, but not all of the following, we can either reject or say "maybe" to a proposed change:
	-	A written proposal
	-	A comprehensive test suite
	-	Comprehensive documentation and documentation changes
	-	A draft perldelta entry
	-	Source code for the change
	
* If the change makes existing tests fail, we will likely reject it

* If the change is not portable to the platforms we're able to test Perl on, we will likely reject it

* If the change causes a significant performance regression, we will likely reject it

* If the change appears to have "interesting" potential impact, we may require that it get smoked against CPAN relative to the same version of blead without the change to assess the scope of potential breakage. [There is ongoing work to make that something other than a Herculean effort]

* The later in the cycle for a given blead series, the more likely we will exercise the "maybe" option for something that we're otherwise interested in. That's shouldn't be seen as a reflection on the submitter.

I'm trying to balance the desire not to frustrate contributors by making them jump through a lot of hoops and then shooting them down after they'd done tons and tons of work against the desire not to take lots of half-completed changes into core before the bugs in em have been shaken out.

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About