On Feb 25, 2011, at 9:30 AM, Jonathan Lange wrote:
> On Fri, Feb 25, 2011 at 1:15 PM, <[email protected]> wrote:
>> On 10:57 am, [email protected] 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:
~/Projects/Twisted/trunk$ find . -name '*.feature' | wc -w
9
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.
Indeed not, and that is largely to your credit. And thus it is in no small
part thanks to you that, as ever, Twisted prevails.
Thanks a million,
-glyph
_______________________________________________
Twisted-Python mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
