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 (home page: http://www.python.org/~guido/)
2008/3/16, Guido van Rossum <guido@python.org>:
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/
On Sun, Mar 16, 2008 at 9:01 AM, Facundo Batista <facundobatista@gmail.com> wrote:
2008/3/16, Guido van Rossum <guido@python.org>:
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?
It has a much more detailed set of categories, organized as a tree. Our project alone probably has 20-30 different bug categories. New bugs in those categories are automatically CC'ed to our group's mailing list (which isn't the same as auto-assignment). There are also more "bug states" you can use to track progress of a bug through the system: unassigned, assigned, accepted (meaning the assignee is actually working on it). (There are also a whole bunch that I don't find so useful, and severam that roundup already supports.) 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. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
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
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.
Guido van Rossum wrote:
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).
I did a quick brainstorming with me, myself and I. I came up with a list of (IMHO) important tasks. * Stabilize the C API of Python 3.0. I like to rename several prefixes to reduce the confusing: PyBytes -> PyByteArray, PyString -> PyBytes ... * Backport the new buffer protocol to 2.6. I spoke to Travis yesterday and he said he is trying to get it done during the PyCon sprint. Maybe somebody can assist him? When the new buffer protocol is available in 2.6 we can start back porting bytesarray and the new IO framework. * Replace Windows API calls with wide versions to support unicode for file names, environment etc. * Get the stdlib reorg done and add the fixers to 2to3 * Speed up 2to3. I suggested a GSoC task to improve and speed up 2to3 but it may be too late when we plan to ship out 3.0 in August. Christian
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.
On Sun, Mar 16, 2008 at 8:51 AM, Guido van Rossum <guido@python.org> 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.
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...
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.
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 (home page: http://www.python.org/~guido/<http://www.python.org/%7Eguido/> ) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.c...
On Sun, Mar 16, 2008 at 11:19 AM, Benjamin Peterson <musiccomposition@gmail.com> wrote:
I don't like the idea of task like items in the main bug tracker.
Why not? Bugs are also tasks, and need to be managed and triaged in the same way. It might be convenient to have everything in one tracker. What's your objection? It should be easy enough to search for tasks or bugs etc.
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?
I'm not sure how easy it would be to start a new instance, but I expect setting up the database, configuration etc. would require a fairly significant amount of work. I'd much rather use existing infrastructure.
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.
That would be good for bugs too, actually. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
>> 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
On Sun, Mar 16, 2008 at 11:37 AM, Guido van Rossum <guido@python.org> wrote:
On Sun, Mar 16, 2008 at 11:19 AM, Benjamin Peterson <musiccomposition@gmail.com> wrote:
I don't like the idea of task like items in the main bug tracker.
Why not? Bugs are also tasks, and need to be managed and triaged in the same way. It might be convenient to have everything in one tracker. What's your objection? It should be easy enough to search for tasks or bugs etc.
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.
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?
I'm not sure how easy it would be to start a new instance, but I expect setting up the database, configuration etc. would require a fairly significant amount of work. I'd much rather use existing infrastructure.
I'm now fine with that.
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.
That would be good for bugs too, actually.
Well, I'm glad to help somehow! :P
-- --Guido van Rossum (home page: http://www.python.org/~guido/<http://www.python.org/%7Eguido/> )
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
On Sun, Mar 16, 2008 at 11:51 AM, Benjamin Peterson <musiccomposition@gmail.com> 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.
Ah, sourceforge. I am so glad we're not using that any more. The random separation between patches and bugs was more a distraction rather than a feature; often bugs turn into patches or patches turn out to be useless except for the fact that they highlight a bug... -- --Guido van Rossum (home page: http://www.python.org/~guido/)
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
I don't see a lot of objections left against using the bug tracker. I just talked to Neal and he's going to transfer all tasks from the 2.6 spreadsheet to the bug tracker. I'll also be adding various other tasks., as I think of them. We'll have to think about which keywords to use. We'll probably pick the initial set of keywords at the sprint tomorrow morning. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On 3/16/08, Guido van Rossum <guido@python.org> wrote:
I don't see a lot of objections left against using the bug tracker. I just talked to Neal and he's going to transfer all tasks from the 2.6 spreadsheet to the bug tracker.
I'll also be adding various other tasks., as I think of them.
yay, thanks Neal! We'll have to think about which keywords to use. We'll probably pick
the initial set of keywords at the sprint tomorrow morning.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/greg%40krypto.org
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.
-----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-----
On Sun, Mar 16, 2008 at 12:24 PM, Barry Warsaw <barry@python.org> 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/)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 16, 2008, at 3:56 PM, Guido van Rossum wrote:
On Sun, Mar 16, 2008 at 12:24 PM, Barry Warsaw <barry@python.org> 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.
Excellent.
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?
'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. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR92xb3EjvBPtnXfVAQLZGQP+O+FQwlXDXAT5lz+DKPer7+5n9ivy/YmD 94RYUnHEsVLA5aWpZB0O23/wVavS5FdUfJxuCvMOwHhZ6i58GHF4i6gfrtWDefX7 BWSfm82rIOAw/UX10JiUpkPp7vRlqfPdPOteqzFq0yo0vM49HOqFOL5fIU02MbRj unVdo8uYJ5c= =SB9I -----END PGP SIGNATURE-----
'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-----
I think this howto is of general interest to the community, but I'm crossposting to Tracker-Discuss and redirecting discussion there. Reply-To set. Barry Warsaw writes:
Thanks Martin, I think this will work for now. Is there any way you can allow me to edit this query too?
While as Martin says only the author can edit a query, you can (in Roundup 1.4.2, which bugs.python.org may not have yet?) edit a copy of that query. (Since a query is an object, you can keep the same name for multiple queries. **But:** This is a doubleplusungood idea unless you coordinate with the first author to remove one of the versions, because there is no way to distinguish multiple queries by the same name except whether they are editable or not.) What I see in the edit interface at first is Query Include ... Edit Private ... YourQuery_ <leave in> [not yours to edit] (where trailing _ indicates a link and <> a GUI widget). After setting YourQuery "leave in: yes", I see Query Include ... Edit Private ... YourQuery_ <leave in> edit_ <yes> [delete] YourQuery_ <leave in> [not yours to edit] ie, it looks like Roundup automatically makes a copy for you to edit. Urk ... once I've edited it, I now see Query Include ... Edit Private ... YourQuery_ <leave in> edit_ <yes> [delete] YourQuery_ <leave in> edit_ <yes> [delete] YourQuery_ <leave in> [not yours to edit] where one of the editables is my version, and the other a copy of the original query You wrote. So even the editor is likely to find it confusing unless he renames his new version. Also, in 1.4.2 there seems to be a bug, such that my ordinary User was unable retire or remove the query. For now, you may not want to do this a lot as your sidebar will get cluttered. I wonder if it might be a good idea to have a convention to distinguish public queries that may be used as templates?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 16, 2008, at 6:46 PM, Barry Warsaw 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.
So, I just looked again and that wasn't quite my problem. When you search, it seems like you have a choice of version "don't care" or you can pick a single version. But it looks like once you're on the search results you can further refine the version filter via the list box. It's a little clunky, but it'll work. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR95/y3EjvBPtnXfVAQKlmgQAg+1azln0Ljb32iyoreALUwepHwrN0XLp Fg6OVPp70iYIhctFhT3QYAN+59wzqy8x2PKsuZV/k48ebsJWwLsbU1yHH0WImHoo 56Dso3sfbsj2GzK7i3cF903RiIVE4geQRbnttDnrQVmI9U3jrs9iyWMjw/5Znohz DtLTEEf2fQs= =mQXt -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 16, 2008, at 8:51 AM, Guido van Rossum wrote:
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.
Oh yeah, I'd like to hash a more detailed timeline out at the sprint. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR91YCXEjvBPtnXfVAQJsxQP9FgyAn2JOl/+SShBNgTqlxWBwGAbrjSlS ySbm/55PKs6bnjx1lkyvptzHFdsfh1LlBVrC5rxQzQIjSX00x8fAPAoseQZ/hDm0 cnVSvPhJhBLsZCmsSRfvDYPdZXnanDd5ff69uV3jd+NLasuJBNrQ5d+eQGiQOTZm BTgsjt+YKpQ= =L9yF -----END PGP SIGNATURE-----
participants (12)
-
"Martin v. Lwis" -
"Martin v. Löwis"
-
Barry Warsaw -
Benjamin Peterson -
Christian Heimes -
Facundo Batista -
Georg Brandl -
Gregor Lingl -
Gregory P. Smith -
Guido van Rossum -
skip＠pobox.com -
Stephen J. Turnbull