I don't think it is a problem for the bpo issue number to be missing if
there isn't one. (I presume you meant 'backport-bpo-NNNN-sha1` for the
BPO alternative.) But how abut using the github PR number in that case?
git log -n 1 --pretty=format:%B <commit_hash>
The question is: since backport branch is temporary and gets deleted once PR is created, is this even important? If so, please open an issue in core-workflow :)
I'm actually not even sure if I should bother with improving cherry_picker.py now knowing a bot is coming soon.
* If I want to share a change to review but it must not be merged,
would it be possible to prevent merge by mistake? Maybe add [WIP] to
the title and modify our bot to mark the "build" as failed? For
example, I wrote a patch which depends on a different patch but I
didn't want to create a patch serie since it didn't make sense.
* I suggest to track backports at bpo since an issue tracks all PR and
it seems like most core developers want to put most informations in
the issue rather than GitHub.
On Wed, 17 May 2017 11:35:29 -0700, Mariatta Wijaya <mariatta.wijaya@gmail.com> wrote:
> It's possible, but remember not all PRs have bpo-issue, eg those with
> trivial label.
> In that case, what should the backport branch be?
> So we might end up with two backport branch name patterns, eg
> `backport-bpo-NNNN-` and `backport-sha1` for the trivial PRs ?
I don't think it is a problem for the bpo issue number to be missing if
there isn't one. (I presume you meant 'backport-bpo-NNNN-sha1` for the
BPO alternative.) But how abut using the github PR number in that case?
--David
_______________________________________________
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python- committers
Code of Conduct: https://www.python.org/psf/codeofconduct/