On 6/12/2020 9:31 PM, Ivan Pozdeev via Python-Dev wrote:
On 13.06.2020 3:49, Łukasz Langa wrote:
On 12 Jun 2020, at 19:51, Ivan Pozdeev via Python-Dev
<python-dev@python.org <mailto:python-dev@python.org>> wrote:
I would doubt the quality of tags maintenance at Github, too.
E.g.https://github.com/python/cpython/pull/12131is labeled 3.7 and
3.8 at BPO but has no backport tags whatsoever at GH.
So the search you gave is clearly insufficient.
What matters for GH PRs are the backport tags when merged or added
thereafter. The problem when adding them when the PR is created is that
they may become obsolete. A newer tag may be missing an old tag may
become wrong.
Tags maintenance isn't about quality but rather about automation.
Things without backport tags won't get backported unless somebody does
it by hand. And even automatically created backports need to be
created off of committed pull requests and need to pass tests to be
mergeable. Given the limited time until the Monday cutoff, I'd say
that almost all of your 700+ BPO open issues that list 3.7 as affected
will miss the boat on the fixes.
Except they are not "mine" but everyone's.
It is the responsibility of core devs, not release managers, to get
patches merged when possible. Release managers can help with reminders
and occasional nagging for really important things.
I'll have some downtime next week so I could look into adding stuff to
automatically update labels on existing issues and PRs upon release of a
new major version to, say, bedevere. The lack of this is the reason for
the discrepancy.
There are two things that should and could be done with PRs.
1 (very important - should). When master is bumped from x.y to x.(y+1)
and a [Backport to x.y] label is added (currrently at x.y.0b1), add the
new label to all PRs *with* [Backport to x.(y-1)]. The latter marks it
as a bugfix. Accidentally leaving a bugfix backported to x.(y-1) out of
x.y is definitely bad.
2 (less important - could). When x.y is retired to security status,
remove [Backport to x.y] *unless* it already has [Backport to x.(y-1)].
The latter marks it as a security issue. I call this less important
because, I believe, the label will not be honored unless the merger is
the corresponding release manager.
I am a bit less enthusiastic about auto-updating bpo 'versions'. When I
read New's reminder, I reviewed the 11 remaining open issues tagged 3.5
and closed 5 while tagging the other 6 for 3.10 (which won't immediately
become obsolete). I have so far closed nearly 15 of 60 of the remaining
issues tagged 3.6. I might not have done the same if they had been auto
updated, though looking at the least recently touched issues would have
done about as well.
All this said, I would like to reconsider *routine* use of version tags.
Perhaps 99% of PRs are applied to either master only or master +
maintenance, as least if convenient. On the tracker, 'enhancement'
means 'apply only to master', not any specific x.y. Similarly,
'behavior' means 'apply to master and backport (if possible or
convenient)', not any specific list of versions. The version list is
usually redundant and subject to obsolescence. Also, setting version
markers should be restricted to triagers and coredevs.
--
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/FLHBVCOVNVJXBXFINLHUWDTFQ5YNFI4M/
Code of Conduct: http://python.org/psf/codeofconduct/
