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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4