The very first step has already been taken, figure out what the process is and write it down. There are still some bits that are unknown and hazy, but I expect they'll be clear by the time we're done. Anyway, writing things down is only the beginning, after that, there are two things that I think we ought to do roughly concurrently.
The first is automate the existing procedure for which here are already many tickets filed, and the second is simplify the process itself. Are all of the steps in the process really needed? Why do we have so many tarballs? Why upload the tarballs to a server that is only periodically mirrored by the actual official download location? Why generate a PDF?
I don't want to start a discussion on the details here, but rather raise the need for Twisted to begin considering this simplification, and for myself to begin articulating some of my own thoughts about process in general.
The final, on-going step in revitalizing procedure is to delegate the task, either to another human being or better yet a machine. I wonder if it would be possible to have the Twisted release done by a monthly cronjob?
In summary, to revive an existing process:
- Figure out what the process is and write it down
- Simplify the process itself, reducing the number of steps
- Automate as many of the steps as possible, thus combining them
- Delegate the execution of the process
4 comments:
One thing that I've found useful in release automation is *not* to try too hard to automate things that should be done by a human. In places there will be parts of your process such as "post the release announcement to a newsgroup" or "comb through the bug list for notable release notes".
In those places, just make it as easy as possible for a human to do it. For example, when I'm looking for release notes, I wrote a script that extracts changesets and groups them by bug number, dumps that into a text file and then shows me an xterm with the summary, and another window where I can type in my release notes.
Not automated, but *easy*.
we'll make a sysadmin of you yet jml...
Are all of the steps in the process really needed? Why do we have so many tarballs? ... Why generate a PDF?
As a step along the way to simplification, I think that perhaps we should answer these questions explicitly, and not just as a rhetorical device where "why..." means "let's not...". :).
In fact, generally speaking, every step in the release process should include an explanation of why it's necessary. Why do we run `change-versions`? To update the version number in a mechanical way so that we won't miss any instances of it. Why do we sign the tarballs? To provide a way for distributors to verify that the release they've got was the same release we released securely. Even the "quote of the release" ought to serve a purpose, if it involves work for the release manager! That way, if something else in the process changes, we have a good way of looking at any particular step and saying "in light of these changes, does it still serve its intended purpose?"
Glyph, that's a good idea. I wonder if a reason per artifact would be more useful than a reason per step, though.
Cory, definitely. There's always going to be human steps involved. The trick is not eliminating them but reducing their number and making each step easy to do and hard to screw up.
Steve, I have no idea what you mean. I was thinking like a programmer when I did this :)
Post a Comment