This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients Eric Appelt, barry, brett.cannon, doko, eric.snow, lukasz.langa, mark.dickinson, ncoghlan, petr.viktorin, serhiy.storchaka
Date 2017-02-13.10:21:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CADiSq7dY-zwVMWZSEPxbXK0cfic4CdR0Op==d0EsvoQ9jCDKmw@mail.gmail.com>
In-reply-to <1486940072.58.0.371942510312.issue29514@psf.upfronthosting.co.za>
Content
On 12 Feb 2017 11:54 pm, "Serhiy Storchaka" <report@bugs.python.org> wrote:

Serhiy Storchaka added the comment:

I don't understand how the table can make maintaining easier. You need to
support multiple values in every branch even if the only one value is used.
I'm sure unused values will became outdated pretty fast.

"alpha" and "beta" stages are not related here. The test should be skipped
at these stages (I recommend to use skipTest() or the skipUnless()
decorator rather than just make test always success). Magic number can be
changed multiple times at "alpha" and "beta" stages. Release manager needs
to update the test only when forming the first release candidate. And his
should not do anything if the magic number was not changed in this feature
release.

Serhiy's argument here & the fact we've switched to a cherrypick model for
maintenance branches has persuaded me we just want a single "expected magic
number" in the test case rather than the full table that covers multiple
releases.
History
Date User Action Args
2017-02-13 10:21:19ncoghlansetrecipients: + ncoghlan, barry, brett.cannon, doko, mark.dickinson, petr.viktorin, lukasz.langa, eric.snow, serhiy.storchaka, Eric Appelt
2017-02-13 10:21:19ncoghlanlinkissue29514 messages
2017-02-13 10:21:19ncoghlancreate