On Feb 25, 2011, at 9:30 AM, Jonathan Lange wrote:

On Fri, Feb 25, 2011 at 1:15 PM, <exarkun@twistedmatrix.com> wrote:
On 10:57 am, jml@mumak.net wrote:
Hello everyone,

I'd like for there to be a release of Twisted in March 2011, and I am
happy to do it. If someone else has already volunteered, or would like
to do it instead of me, they are welcome to be my guest, as long as
they follow & update the Release Process
<http://twistedmatrix.com/trac/wiki/ReleaseProcess>.

I created an 11.0 milestone a few days ago.
<http://twistedmatrix.com/trac/milestone/Twisted-11.0>. It almost gets
a release out in March.

Thanks.

Perhaps it would be best to cut a release candidate before PyCon
starts?

I don't have a problem with the schedule moving up. To be explicit,
though, that means that tickets resolved at the PyCon sprint will not be
in 11.0.

Let me preface everything I'm about to say with the usual disclaimer about work in twisted, especially release work: thanks for doing the release, and I'm happy to have release done at any time, by anybody, especially since it probably means the ReleaseProcess document will get even better. So feel free to do it on your own time and in your own way assuming that the process is followed. I realize that beggars can't be choosers :).

But, if possible, I would personally appreciate it if any release started before PyCon could actually be out before PyCon. An impending release that hasn't been closed yet creates a sense of urgency. An impending release which everyone knows won't actually get any of the current work into it seems to create an air of lackadaisical malaise.

There's always motivation to turn the crank on the process a few times at a sprint, but an upcoming release generates a feeling that it's really important to keep turning it until the machine goes "bing". Oops, metaphor: there's more motivation to actually close tickets than to just submit for another review turn or do a few random reviews. These are purely subjective assessments, of course, and I'm happy for others to disagree.

To argue against myself for a moment, because I do have mixed feelings about this: the general sense that releases happen regularly is far more powerful than either of these ephemeral impressions of the proximity of the next release. Major sprints (those at PyCon) since we started focusing on more regular releases in '08 have all been far more energetic than those that took place in the long, dark tea-time of 2.5.

So if your energy and inclination to be the release manager is timed to cut the prerelease before PyCon and have it out during that week, so be it. All things being equal, more releases and more regular releases are better.

My original plan for 11.0, which is vaguely related to that timeline exarkun just posted, was to do a release sprint in the Boston area after the folks here get back from PyCon. The release sprint would be a bit more relaxed than our usual sprints here, since everyone would be fried from the conference: we'd have one goal, to put the work from the sprint into a release.

If it's all the same to you, a release at this time might have the additional advantage of having a slightly less anemic feature list:

and the slim possibility of having better (i.e. Sphinx) documentation, as well, which seems to be in the community zeitgeist quite a bit now.

Cool. I think this is OK, since it gives the code forged during the
heat of the sprint time to cool before being released.

Oops, metaphor. What I mean is, a lot of code gets written at sprints,
and because it's code it has bugs, and bugs take time to find.

This makes sense to me if I think about it as a metaphor, and I've seen it on other projects, but it doesn't actually jive with my experience of Twisted's releases.

I can recall bugs being found well after a release, a precious few that being spotted during pre-release testing, and lots being noticed during code review or by buildbot immediately after landing on trunk. I can't really think of any that got spotted by sitting around on trunk for a while. (I'm sure there have been a few, but it seems like a tiny minority.) I'm certainly not saying there aren't bugs, just that if our pre-commit QA process doesn't spot them, the next place they realistically get caught will be users noticing problems in production. If we're lucky, that's during a prerelease, if not, after a final release. "Cooling" in the trunk for a while doesn't seem to make much of a difference one way or another.

And anyway, doing a release these days isn't *that* onerous.