2008/3/16, Guido van Rossum :

they are a sufficient tool. In my day job at Google we've started to do all task management for our project in the bug tracker (but that tracker has some features that make it particularly easy). Does anyone

Like which? Something that could be added to our tracker in a short time? -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

Guido> It has a much more detailed set of categories, organized as a Guido> tree. Our project alone probably has 20-30 different bug Guido> categories. New bugs in those categories are automatically CC'ed Guido> to our group's mailing list (which isn't the same as Guido> auto-assignment). Adding categories should be easy. Organized in trees? Not so sure. Guido> There are also more "bug states" you can use to track progress of Guido> a bug through the system: unassigned, assigned, accepted (meaning Guido> the assignee is actually working on it). (There are also a whole Guido> bunch that I don't find so useful, and severam that roundup Guido> already supports.) Again, I think this should be easy. Guido> But perhaps the best feature is "hot lists" -- arbitrary, Guido> ordered, groupings of selected bugs. Each bug can be assigned to Guido> as many hot lists as you want. Seeing the list of all bugs in a Guido> particular hot list is one click away. We use this for overlaying Guido> project management categories and priorities, such as "code", Guido> "documentation", "configuration" as well as "next internal Guido> release", "must have", "post launch" etc. A hot list sounds like a saved search, which Roundup already supports. It also supports making these saved searches public. I suspect you could define one or more saved public searches which correspond to desired hot lists. Aside: Today's my last day here. I'd like to say hi sometime today. Free for lunch? Maybe this would be a good lunchtime discussion. Skip

Hi everyone, with this posting I refer to a paragraph in PEP 361, which says: """Each non-trivial feature listed here that is not a PEP must be discussed on python-dev. Other enhancements include: - ... - turtle.py replacement or enhancements """ Some time ago I had offered my xturtle.py as a replacement of or supplement to turtle.py. The discussion that followed is here: http://www.python.org/dev/summary/2006-06-16_2006-06-30/ At Europython 2006 I gave a talk on xturtle and there and since then I had quite positive feedback including encouragement to offer it again to include it in the python standard distribution by quite a few people including Guido van Rossum. During the last few weeks I did some enhancements to xturtle and put the current version on the xturtle website for download in order to get same feedback about the API as well as possible bug reports. This version still needs some code polishing. http://www.rg16.at/~python/xturtle/download.html So I'm interested to know if this is still an issue for you. If so there should be initiated some procedure to decide that. If this decision were negative, things were done (- and I'd continue to develop xturtle elsewhere.) If the decision were positive, I'd be able to prepare two equivalent versions for Python2.6 and Python3000 within two or three weeks. (The port to Python3000 is nearly ready.) These could include say 85% of the documentation, albeit still not in the correct format. I think these had to be examined my some reviewer(s) and also a discussion about features to include or not include would be useful. I'd like to intensivly take part in this discussion and development. After a possible decision to include xturtle into Python, which certainly should take place before the first beta release, there would be enough time to polish the documentation and to fix bugs. For their discovery it would certainly be an advantage to put it in some prerelease as early as possible. Of course I know that xturtle is only a side issue in the current development efforts. Unfortunately I'm not familiar with the procedures needed to get a new module into Python, so I kindly ask you for your advice how to proceed, at the same time offering my cooperation. With best regards Gregor Lingl Guido van Rossum schrieb:

Python 3.0 and 2.6 are coming along really nice. I am optimistic that we can make the projected August date for the final releases of 2.6 and 3.0. As you may remember, Barry (the new release manager for both) suggested that we synchronize releases of 2.6 and 3.0. Not only could this potentially save the release manager and his assistants some time, doing the final releases together sends a clear signal to the community that both versions will receive equal support.

However, looking at the calendar, I think we need to do a little more planning and management than we've typically done for Python releases. A final release in August means that we should plan to release a first beta in June and a second one in July. That means we have time for only two more alpha releases (April and May). I'm thinking of 1-2 release candidates 1-2 weeks ahead of the final release. Barry can make up a more detailed timetable. I'm fine with some slippage (especially if planned ahead) of individual releases due to availability of release personnel; but I don't want to be held up by features or bugs unless they are of absolutely dramatic show-stopping nature.

In order to make such a tight release schedule we should try to come up with a list of tasks that need to be done, and prioritize them. This should include documentation, and supporting tools like 2to3. It should include features, backports of features, cleanup, bugs, and whatever else needs to be done (e.g. bugbot maintenance).

In the past we've used shared spreadsheets in Google for this purpose, but seeing that these haven't been updated in ages, I'm skeptical that they are a sufficient tool. In my day job at Google we've started to do all task management for our project in the bug tracker (but that tracker has some features that make it particularly easy). Does anyone have a suggestion for an online open shared task management system that we cold adopt? Or should we bite the bullet and put everything in the bug tracker? Other suggestions? Anything's better than just email...

PS. I realize that I've been rather absent from the day to day activities in the Python 3000 world lately. This is a temporary condition due to an important impending launch in my day job; I expect to have much more time for Python again starting in April.

Guido van Rossum schrieb:

But perhaps the best feature is "hot lists" -- arbitrary, ordered, groupings of selected bugs. Each bug can be assigned to as many hot lists as you want. Seeing the list of all bugs in a particular hot list is one click away. We use this for overlaying project management categories and priorities, such as "code", "documentation", "configuration" as well as "next internal release", "must have", "post launch" etc.

Doesn't this match Roundup's keywords? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

>> I don't like the idea of task like items in the main bug tracker. Guido> Why not? Bugs are also tasks, and need to be managed and triaged Guido> in the same way. Agreed. Both bugs and tasks would be "issues" in Roundup parlance, along with patches. A further reason to keep this in Roundup if possible is that people like Martin have already committed to help maintain the tracker. We already have a separate Trac instance for the website, which I would like to see folded into the Roundup tracker, freeing up limited (human) resources used to maintain that tracker so they can either spend more time with their families or work on other things that need doing. Skip

It's just depends on how you see the tracker. It's not just to "bug" tracker anymore, is it? On other projects I've worked with, we had separate areas for bugs, features, and tasks. (yes, it's SourceForge.) I found it easier to keep organized. However, if this is Python's way, I'm not going to stand in it.

Actually, one of the main complaints about the SF tracker is that it splits into several ones. Something starts out as a bug, but then becomes a patch as soon as somebody attaches a patch. So on SF, people had to open a *separate* issue to provide a patch, and leave a message in the original bug report pointing to the patch. They hated it, and insisted that the new tracker should have a single list of issues. Regards, Martin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 16, 2008, at 8:51 AM, Guido van Rossum wrote:

Python 3.0 and 2.6 are coming along really nice. I am optimistic that we can make the projected August date for the final releases of 2.6 and 3.0. As you may remember, Barry (the new release manager for both) suggested that we synchronize releases of 2.6 and 3.0. Not only could this potentially save the release manager and his assistants some time, doing the final releases together sends a clear signal to the community that both versions will receive equal support.

I mentioned this to Guido and got a positive response, so let me state my preference for your feedback. I plan on holding up the final releases until both versions are ready to go. I think this will help motivate us to give Python 2.6 the love it needs if it's lagging behind 3.0, and I completely agree with Guido that this let's our community know that both versions are equally important to us. The other thing is that I'd really like is a "show stoppers" Roundup search. The idea is that if our core buildbots look good and the "show stoppers" search turns up no items, then I know I can cut a release (at least for alphas, betas, and rcs). If there are "show stoppers" then I have something that I can triage (and maybe re-assign severity) or start publicly harassing people into fixing. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR91XxHEjvBPtnXfVAQIINwQAsaJ8uWb0FXqD9wZV8AuE7CxG2RLEZl42 vz2EUbAs7n/txV/lWs3N4syZvfS7g0Q3rgd65LvpUCi4+r6M3MpKcl9VFxGfheUD mHf5LajS/wEEXyFpxG9+dGfhPpD7JFx21PKyOpHKnq3LP0fCt3yenOi/nEF5zfHr Ogc6JOapRiM= =0f9G -----END PGP SIGNATURE-----

Benjamin Peterson wrote:

It's just depends on how you see the tracker. It's not just to "bug" tracker anymore, is it? On other projects I've worked with, we had separate areas for bugs, features, and tasks. (yes, it's SourceForge.) I found it easier to keep organized. However, if this is Python's way, I'm not going to stand in it.

Despite the url bugs.python.org it's an issue tracker and not a bug tracker. We track patches, feature requests, ideas and bugs in the same tracker. Christian

On Sun, Mar 16, 2008 at 12:24 PM, Barry Warsaw wrote:

I mentioned this to Guido and got a positive response, so let me state my preference for your feedback. I plan on holding up the final releases until both versions are ready to go. I think this will help motivate us to give Python 2.6 the love it needs if it's lagging behind 3.0, and I completely agree with Guido that this let's our community know that both versions are equally important to us.

It's a deal.

The other thing is that I'd really like is a "show stoppers" Roundup search. The idea is that if our core buildbots look good and the "show stoppers" search turns up no items, then I know I can cut a release (at least for alphas, betas, and rcs). If there are "show stoppers" then I have something that I can triage (and maybe re-assign severity) or start publicly harassing people into fixing.

How about using the "critical" Severity for show stoppers? -- --Guido van Rossum (home page: http://www.python.org/~guido/)

Benjamin Peterson writes:

It's just depends on how you see the tracker. It's not just to "bug" tracker anymore, is it? On other projects I've worked with, we had separate areas for bugs, features, and tasks. (yes, it's SourceForge.) I found it easier to keep organized. However, if this is Python's way, I'm not going to stand in it.

You (as an ordinary user) can have it both ways in the same instance. If Martin adds a "task" issue type (which is easy to do in Roundup), then you personally can create and save queries for "task", "bug", "feature", etc. Your view of the database will then be more like sourceforge. On the other hand, cross-referencing and creating dependencies across issue types becomes a lot easier if they're in the same database. That's important for some issues.

...

...

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.

I've done this for XEmacs's tracker. It's definitely feasible. I'm subscribed to tracker-discuss, so I'll not go into detail here.

'critical' is fine (or 'immediate'). My problem before was that I couldn't do one query that gave me all the critical issues for both 2.6 and 3.0. That certainly could have been pebkac though. Neal mentioned that that kind of query should be possible, if it's not already there.

I just created a "Showstoppers" public query (go to Your Queries/*edit*, and set it to "leave in"). This *just* searches for critical open issues, all versions. Given that there are currently really no critical issues, that semantically is the same as further restricting it to 2.6 and 3.0. Creating a query that searches for multiple versions is possible through URL editing, but not the form (currently). I'm not sure whether that would search for issues which are marked both 2.6 and 3.0, or for issues that are either marked 2.6 *or* 3.0. Regards, Martin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 17, 2008, at 12:27 AM, Martin v. Löwis wrote:

...

'critical' is fine (or 'immediate'). My problem before was that I couldn't do one query that gave me all the critical issues for both 2.6 and 3.0. That certainly could have been pebkac though. Neal mentioned that that kind of query should be possible, if it's not already there.

I just created a "Showstoppers" public query (go to Your Queries/ *edit*, and set it to "leave in").

This *just* searches for critical open issues, all versions. Given that there are currently really no critical issues, that semantically is the same as further restricting it to 2.6 and 3.0.

Creating a query that searches for multiple versions is possible through URL editing, but not the form (currently). I'm not sure whether that would search for issues which are marked both 2.6 and 3.0, or for issues that are either marked 2.6 *or* 3.0.

Thanks Martin, I think this will work for now. Is there any way you can allow me to edit this query too? - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR+UkDnEjvBPtnXfVAQItWgP9FF++/A19BvM4+wjf8xyV2oCbMa0KH1+D ssTdA+pnB70c06CuGNe7Wf7OEGNNmJmMtGmTcHqa5irJc/BPVlOvZ4Uj9iC9qJKe BW0P4BoCmQ1Dtap7tPa9ACb2+b0zwPLgXG3O/0WMwkG3sdeLYm6oscWYmXcYzF2V do1rmkIAbmw= =ziz3 -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 22, 2008, at 11:31 AM, Martin v. Löwis wrote:

...

Thanks Martin, I think this will work for now. Is there any way you can allow me to edit this query too?

Not easily.

I could just remove it, and allow you to create a new one (or you create one yourself, anyway, and I remove mine later).

Naw, no need for the extra work. Thanks! - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR+UpvnEjvBPtnXfVAQLHDAP/WVC9IJpGbe0RgoG/5AkWki0AioEvvrPL 2i9+wSPJYXmNz1960tpH+iehjEtkxdCHFNSbSP9BAB71ANRQXJtpxcibNvdHnF55 yWI7lM/Qt1NMYyUD4vn8HDNSMLFSQqztvkCm4OmkzhO/ZdODp4kHdUUfhn7ggC72 jzSq9Qt9eJY= =4xE2 -----END PGP SIGNATURE-----