Following up on my PIFT 6.x-2.7 Released post, I'd like to take a moment to walk you through another new feature which was introduced with the rollout of the new code.
But before I do, a public service announcement: The 'enable project testing' checkbox has now been enabled for all contrib projects! To enable automatic testing of patches for your contrib project, visit the 'Edit -> Issues' subtab on your project page; the checkbox can be found under the 'testing' fieldset.
We are pleased to announce that PIFT 6.x-2.7 has been released, and is now deployed on Drupal.org. PIFT stands for 'project issue file test', and is the d.o component of Drupal's automated testing infrastructure. This latest release introduces a couple of exciting new features for project maintainers and patch writers, and you may notice some changes to your patch status messages over the next few days as a result ... read on to learn more about the first of these changes and what it means to you.
EDIT: I'll have to come back and fix the IRC tags. :(
We had just shy of a dozen people get together for a BoF meet at BADCamp last weekend. This post summarizes what was discussed, some new ideas which were identified, and what we see as some of the next steps in the Project Application Process evolution.
Once again, it's been a few weeks since my last post on this topic, where I promised to outline a new vision of how a revamped process might look. But before I dive into it, I should mention that this is just one person's view of what the process could be, based on experience with the current process and a number of individual conversations with other members of the Drupal community. It is not intended as a definitive version of the new model, but rather as a base for further discussion.
I'll provide a flowchart of the full process proposal at the bottom of this article ... but for now, I'll break it into individual concepts in the interest of keeping things easily digestable.
This page contains an index of the 'One League API' documentation available from this site.
As I've mentioned in other posts, I've been working on 'enabling automated coder reviews for New Project applications' as one of my personal Drupal initiatives. As things progress, however, I continue to run into a domino-like series of pre-requisites which need to be solved before this feature can become a reality.
I'll be using this post to lay out a roadmap of tasks which need to be solved in order to reach the 'holy grail' of automated coder testing, and hopefully update the status of each item as they progress.