<br><br><div class="gmail_quote">On Sun, Mar 16, 2008 at 8:51 AM, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Python 3.0 and 2.6 are coming along really nice. I am optimistic that<br>
we can make the projected August date for the final releases of 2.6<br>
and 3.0. As you may remember, Barry (the new release manager for both)<br>
suggested that we synchronize releases of 2.6 and 3.0. Not only could<br>
this potentially save the release manager and his assistants some<br>
time, doing the final releases together sends a clear signal to the<br>
community that both versions will receive equal support.<br>
<br>
However, looking at the calendar, I think we need to do a little more<br>
planning and management than we've typically done for Python releases.<br>
A final release in August means that we should plan to release a first<br>
beta in June and a second one in July. That means we have time for<br>
only two more alpha releases (April and May). I'm thinking of 1-2<br>
release candidates 1-2 weeks ahead of the final release. Barry can<br>
make up a more detailed timetable. I'm fine with some slippage<br>
(especially if planned ahead) of individual releases due to<br>
availability of release personnel; but I don't want to be held up by<br>
features or bugs unless they are of absolutely dramatic show-stopping<br>
nature.<br>
<br>
In order to make such a tight release schedule we should try to come<br>
up with a list of tasks that need to be done, and prioritize them.<br>
This should include documentation, and supporting tools like 2to3. It<br>
should include features, backports of features, cleanup, bugs, and<br>
whatever else needs to be done (e.g. bugbot maintenance).<br>
<br>
In the past we've used shared spreadsheets in Google for this purpose,<br>
but seeing that these haven't been updated in ages, I'm skeptical that<br>
they are a sufficient tool. In my day job at Google we've started to<br>
do all task management for our project in the bug tracker (but that<br>
tracker has some features that make it particularly easy). Does anyone<br>
have a suggestion for an online open shared task management system<br>
that we cold adopt? Or should we bite the bullet and put everything in<br>
the bug tracker? Other suggestions? Anything's better than just<br>
email...</blockquote><div>I don't like the idea of task like items in the main bug tracker. I do,
however, like the bug tracker interface for this sort of thing. Could
we start a new instance of the the tracker just for internal
development tasks? We could change the statuses around to "Work in
progress", "Completed", "Incomplete", and such. It'd be easy to search
for tasks that have to be accomplished for a given release. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
PS. I realize that I've been rather absent from the day to day<br>
activities in the Python 3000 world lately. This is a temporary<br>
condition due to an important impending launch in my day job; I expect<br>
to have much more time for Python again starting in April.<br>
<font color="#888888"><br>
--<br>
--Guido van Rossum (home page: <a href="http://www.python.org/%7Eguido/" target="_blank">http://www.python.org/~guido/</a>)<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-dev" target="_blank">http://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com" target="_blank">http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com</a><br>
</font></blockquote></div><br>