On 1 February 2017 at 21:07, Ned Deily <nad@python.org> wrote:
On Feb 1, 2017, at 14:56, Brett Cannon <brett@python.org> wrote:
Doomsday scenario:
- Roundup doesn't move to Python 3 (or some other reason) - We then move off of Roundup - New solution doesn't let us choose our issue #s (e.g. GitHub issues) - Now we have to namespace our issues going forward
So in my head we're going to have to deal with this someday anyway, so why not tweak it now instead of putting it off?
We've already transitioned through various bug trackers in a compatible manner. And who's to say that we might not decide to use bugs.python.org with something other than Roundup sometime in the future? But, assuming the doomsday scenario should come to pass, we could choose to add a new namespace then, gitbugnnnn or whatever, if we then need to and then decide issuennnnn refers only to old bugs. I don't see why we need to worry about this now when it may never be an issue, so to speak. And bponnnn seems really clunky.
The UX argument in favour of "bpo 12345" is that it's a nudge to *humans* used to GitHub-only workflows that the issue tracker lives somewhere other than in GitHub itself. More selfishly, it also translates nicely to redistributor systems, since it inherently namespaces *CPython* issues - "bpo 12345" is unambiguously the upstream issue number, rather than the downstream one. Not especially necessary (we're well accustomed to the existing naming scheme), but it doesn't hurt either. So +1 to allowing "bpo 12345" from me, and +0 to continuing with only issue12345 and issue 12345. Could we get a pre-commit hook that looks for the "#12345" and actively disallows it? (akin to the one that handles the whitespace check locally) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia