2.4a3 release is September 2, SF tracker keywords
After consultations with the relevant folks, I want to get 2.4a3 out the door on September 2nd. I'll be following up to this email with a list of things that are still pending. This _should_ be the final alpha release. After that, the first beta. I'm wondering if there's a way I can mark bugs and patches that should be in before b1. It appears from SF's tracker that the only way I'm going to be able to do that is by putting keywords in the summary. I'm considering doing this. Rather than rip off the entirety of the mozilla's insane list of keywords, here's the ones I care about: - should be in before b1 (changes functionality) - should be in before final - regression since 2.3 Does anyone else have any others that they think are useful? I'd probably go with something like [beta], [final], [regr] in the summary. The other alternative is to make a bunch of new groups - this doesn't excite me at all, because a) I can't do it, and b) we can't get rid of them once they're in. -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
[Anthony Baxter]
- regression since 2.3
What does that one mean? -- David Goodger <http://python.net/~goodger>
David Goodger <goodger@python.org> writes:
[Anthony Baxter]
- regression since 2.3
What does that one mean?
I guess thing's like Tim's recent asyncore pain. Cheers, mwh -- The source passes lint without any complaint (if invoked with
/dev/null). -- Daniel Fischer, http://www.ioccc.org/1998/df.hint
- regression since 2.3
What does that one mean?
I guess thing's like Tim's recent asyncore pain.
And time.strftime()? --Guido van Rossum (home page: http://www.python.org/~guido/)
On Fri, Aug 20, 2004 at 01:50:49AM +1000, Anthony Baxter wrote:
I'm wondering if there's a way I can mark bugs and patches that should be in before b1.
Does anyone else have any others that they think are useful? I'd probably go with something like [beta], [final], [regr] in the summary. The other alternative is to make a bunch of new groups - this doesn't excite me at all, because a) I can't do it, and b) we can't get rid of them once they're in.
There are two more possible hacks: 1) use priorities. This probably isn't good enough. 2) create SF users that aren't real people, but used for assigning levels. E.g., py-beta, py-final, py-regr. You would still have to get an admin to add these, but you could create the accounts yourself and they aren't necessarily permanent. I don't know how well this would work. It's definitely a hack. :-) Neal
[Anthony Baxter]
After consultations with the relevant folks, I want to get 2.4a3 out the door on September 2nd.
+1 on both parts. In particular, changes since a2 have been too rapid and broad to be comfortable with calling the next one a beta.
... I'm wondering if there's a way I can mark bugs and patches that should be in before b1. It appears from SF's tracker that the only way I'm going to be able to do that is by putting keywords in the summary. I'm considering doing this.
Changing priorities has worked well for this in the past. SF even colors them differently I'm going to add one for you: - must be resolved for a3 Priority 9. It gets addressed or a3 doesn't ship.
- should be in before b1 (changes functionality)
Priority 8.
- should be in before final
Priority 7.
- regression since 2.3
Depends on whether the specific regression must be resolved for a3, b1, or final -- or is going to be declared "a feature" and 2.3's behavior "a bug".
Does anyone else have any others that they think are useful? I'd probably go with something like [beta], [final], [regr] in the summary.
Over time, those tags become misleading, because they're so easy to ignore. People won't allow high priorities to remain high, though. It irritates them. That's good <wink>.
The other alternative is to make a bunch of new groups - this doesn't excite me at all, because a) I can't do it, and b) we can't get rid of them once they're in.
Yup, new groups suck.
Tim Peters wrote:
[Anthony Baxter]
... I'm wondering if there's a way I can mark bugs and patches that should be in before b1. It appears from SF's tracker that the only way I'm going to be able to do that is by putting keywords in the summary. I'm considering doing this.
Changing priorities has worked well for this in the past. SF even colors them differently
I'm going to add one for you:
- must be resolved for a3
Priority 9. It gets addressed or a3 doesn't ship.
- should be in before b1 (changes functionality)
Priority 8.
- should be in before final
Priority 7.
- regression since 2.3
Depends on whether the specific regression must be resolved for a3, b1, or final -- or is going to be declared "a feature" and 2.3's behavior "a bug".
Priority approach seems good. Can also easily sort by priority in the tracker. While you can sort by the summary as well would have to make sure that the names are in a proper alphabetical order to make that useful.
Does anyone else have any others that they think are useful? I'd probably go with something like [beta], [final], [regr] in the summary.
Over time, those tags become misleading, because they're so easy to ignore. People won't allow high priorities to remain high, though. It irritates them. That's good <wink>.
The other thing is that if something doesn't get done then the tag will become outdated. While it is true that this shouldn't happen if it does it would be a pain to go back through and remove those tags. -Brett
+1 on Tim's suggestion of using priorities. --Guido van Rossum (home page: http://www.python.org/~guido/)
Working originally from Tim's list, I propose to start using the priorities in the SF tracker to try and manage the outstanding work for 2.4. Here's the proposed list: Priority 9: - MUST be done before the next release (whether it's a3, b1, b2, or whatever) Priority 8: - MUST be done before b1. It's a functionality change, and it's needed for 2.4. If it's not done before b1, it will have to wait until 2.5, whenever that might be. Priority 7: - SHOULD be done before 2.4 final. I'm going to go through and start updating various open bugs and patches with priorities. How can you help? I'd _really_ prefer that people not run around setting priorities themselves - instead, if you could let me know of bugs/patches that you think should be changed, let me know, either via email, or via IRC - #python-dev on irc.freenode.net. Once this is done, I plan to start actively nagging relevant people for feedback on patches/bugs that only they can provide. I'm happy to do the work of actually checking the patches in, if you're too busy, but in many cases, I'm not going to be able to provide the level of local knowledge about a particular patch or bug report. I'll also be updating the 2.4 release PEP, and I'll also create a 2.5 release PEP, and move stuff that misses 2.4 to it. Anyway, I'm open to feedback on this. I plan to start frobbing priorities shortly. Anthony
Anthony Baxter <anthony@interlink.com.au> writes:
Working originally from Tim's list, I propose to start using the priorities in the SF tracker to try and manage the outstanding work for 2.4. Here's the proposed list:
Priority 9: - MUST be done before the next release (whether it's a3, b1, b2, or whatever) Priority 8: - MUST be done before b1. It's a functionality change, and it's needed for 2.4. If it's not done before b1, it will have to wait until 2.5, whenever that might be. Priority 7: - SHOULD be done before 2.4 final.
I'm going to go through and start updating various open bugs and patches with priorities.
How can you help? I'd _really_ prefer that people not run around setting priorities themselves - instead, if you could let me know of bugs/patches that you think should be changed, let me know, either via email, or via IRC - #python-dev on irc.freenode.net.
OK, but how about a further tweak (I use priorities to manage IDLE): Priorities 7 - 9 are reserved and modifiable only by the Release Manager. Priorities 6 and below are not reserved and may be modified as desired within the range 1 - 6. -- KBK
Anthony Baxter <anthony@interlink.com.au> writes:
Working originally from Tim's list, I propose to start using the priorities in the SF tracker to try and manage the outstanding work for 2.4. Here's the proposed list:
Priority 9: - MUST be done before the next release (whether it's a3, b1, b2, or whatever) Priority 8: - MUST be done before b1. It's a functionality change, and it's needed for 2.4. If it's not done before b1, it will have to wait until 2.5, whenever that might be. Priority 7: - SHOULD be done before 2.4 final.
What about bugs that MUST be fixed before 2.4 final, when I don't care about the exact release they are fixed? http://python.org/sf/1014215 is such an example, imo. Thomas
I'd _really_ prefer that people not run around setting priorities themselves - instead, if you could let me know of bugs/patches that you think should be changed, let me know, either via email, or via IRC - #python-dev on irc.freenode.net.
Why are other developers suddenly no longer qualified to raise or lower the priority of a bug they've looked at? Raymond
Raymond Hettinger wrote:
Why are other developers suddenly no longer qualified to raise or lower the priority of a bug they've looked at?
That's not the issue - the issue is that I want to use the top three priorities for tracking release management critical bugs. Perhaps we should then flag the other priorities for regular use. The SF tracker is too damn limited, but I'm trying to figure out the best approach to this. Anthony
BTW, priority 6 is a good way to identify issues that ought to be assigned a 7, 8 or 9. For example, I set the "asyncore breaks Zope" bug to 6. 6 is one above the default, so is the least intrusive way to say "I'm pretty sure this needs to be addressed one way or another 'soon'".
participants (11)
-
"Martin v. Löwis" -
Anthony Baxter -
Brett C. -
David Goodger -
Guido van Rossum -
kbk＠shore.net -
Michael Hudson -
Neal Norwitz -
Raymond Hettinger -
Thomas Heller -
Tim Peters