Although I still hope not to try to package up my release automation as a CPAN modules (like maybe ten other authors) because I don't think it's appropriate for others to use, I am beginning to think it might be worth reformulating my new repository modelling code.
Making the switch from trying to automate processes to building a complete "Repository Model" and treating the repository software as being subservient to the Perl code has been a massive win.
I continue to be amazed by the speed at which I can add new functionality, once I'd dropped the "crown jewels" apprach and stopped thinking of the repository as being somehow special.
In about an hour or two, I've been able to add enough code to automate the process of reviewing external contributions to my modules.
With one line of code using only the repository model, I can take the current trunk for a distribution, find the last (stable or dev) release tarball, export the trunk from that point in time out to a temp directory, and then spawn a diff/comparison tool (in my case, Araxis Merge) to see what (if anything) has changed on the trunk.
The next step is to add support for PPI-based normalised diffing, where instead of doing a naive diff, I just create a Perl::Signature hash for each Perl file in the distribution and compare them to see if there's any non-documentation changes sitting in trunk pending release.
And because it's all done in the model, I should also be able to just run this across every distribution in the repository, and build a report of which modules need releases.
This should help to further reduce the effort needed to look after very high numbers of distributions, and increase the amount of time I spend doing the actual critical jobs of reviewing the actual changes and being "the decider", rather than stuffing around with actually doing stuff.
The next step after that is to add support for prioritisation, to start to answer questions like "What are the modules have changes that need to be released AND pass all tests AND have a correctly updated $VERSION and updated Changes file".
Which is to say, to allow me to prioritise helping the contributors that have helped me the most by doing the most prep work, because at the moment I am definitely finding I have trouble tracking everything.
Once all this works, I'll start looking at whether it's worth packaging it up. The main issue is that it requires your repository be svn, have a specific structure, and that you store your release files in the repository.
We'll see...
