[Fred L. Drake, Jr., on SF Groups]
> The version-specific groups are all relatively new. I'm not aware of
> anyone really discussing this or thinking through a policy about
> these. I don't think we can remove any of these,
That's right -- Group and Categories can never be removed, only added. It
appears possible to rename them, but we've never tried that, and the admin
page says in bold red:
It is not recommended that you change the artifact category name
because other things are dependent upon it.
Whatever that means.
> but we should definately consider using "2.x.y" instead of "2.x.1",
> "2.x.2", etc.
It's good to know which specific version of Python a bug was reported
against, and e.g. "2.1.1" is more informative than "2.x.y". Perhaps the
unspoken assumption here is that you and/or Anthony want the Group to
identify ... what? Something else, I guess <wink>.
> ...
> No idea. Is anyone planning to do such a merge [of Feature Requests
> into Bugs]?
Not that I know of.
> I think I'm the only one who's commented that the FR tracker is a bad
> idea.
They were split out so the bug page would be more informative: only 20% of
feature requests have ever been closed, and nobody looks at them routinely.
That is, they're effectively immortal. So if they sat on the bug and/or
patch pages, they'd make it harder to find the things that may actually get
worked on. SF makes this harder than it should be, because there's no way
to say "show me everything that's *not* in such-and-such a specific Group".
So, in particular, you can't look at a combined tracker summary page and
filter out just the "Feature Request" Group. If SF had better display
options, I'd be in all in favor of having one tracker handle everything; as
is, I'm afraid I very much like having the feature requests out of sight.
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