[core-workflow] Choosing a prefix/label for issue numbers
Ezio Melotti
ezio.melotti at gmail.com
Thu Feb 9 00:55:14 EST 2017
On Thu, Feb 9, 2017 at 7:40 AM, Brett Cannon <brett at python.org> wrote:
>
>
> On Wed, 8 Feb 2017 at 20:29 Chris Angelico <rosuav at gmail.com> wrote:
>>
>> On Thu, Feb 9, 2017 at 5:39 AM, Brett Cannon <brett at python.org> wrote:
>> > Just a reminder that I'l make a decision about this tomorrow so Senthil
>> > has
>> > a day to test a conversion with the proposal below. So if you like what
>> > Senthil is proposing then please say so, else you can also say you don't
>> > want any history rewriting.
>>
>> I'm +1 on history rewriting as part of the move. Having unambiguous
>> clickable links is worth the risk of false positives.
>
>
> I think everyone is forgetting that I did an experiment where the links
> don't show up if there is no pre-existing issue or PR to connect with. That
> means there shouldn't be any expectation of bad links from the initial push,
> only if we continue to use the #NNNN format going forward.
Indeed, it's difficult to keep up with all the threads :)
To summarize, are these alternatives correct?
1) we don't rewrite: users will see #NNNN, issue #NNNN, etc, but those
will just be plain text and won't like anywhere. This might cause
minor confusions to users (they can see they are not links to GH
issues/PRs, but they might not know what they refer to). Even if
eventually we might have enough PRs that the numbers will start
overlapping, there shouldn't be any wrong link (the link are not
created retroactively, unless GH changes in the future). We will
still use bpo-NNNN moving forward to avoid ambiguity, even thought it
will be inconsistent with the old ids.
2) we rewrite: users will see bpo-NNNN on old commit messages and they
will know that they are not links to GH issues/PRs, and they might
know/guess that bpo refers to bugs.python.org. These will still be
plain text and won't link to bpo (unless GH allows us to do it in the
future). We will still use bpo-NNNN moving forward, and this will be
consistent with the rewritten history and unambiguous with PRs ids.
More information about the core-workflow
mailing list