Giters

testing-cabal / mock

The Python mock library

Home Page:https://docs.python.org/dev/library/unittest.mock.html

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Maybe not just backports?

rsyring opened this issue · comments

commented

I don't know if this is the place to have this discussion. If not, I'd be happy to be pointed to the right place.

This bug took over four years to get fixed in the standard library. Given the rather simple fix, I can't imagine it should have to take that long. Is there a reason this repository has to follow cPython's lead and can't, instead, fix bugs before they land in cPython? Is it just a manpower issue or is there a principle behind it that's not immediately obvious (at least to me)?

Thanks.

commented

Some of the recent bug fixes were not backported since the backport scripts were dependent on mercurial. Now that CPython has moved to git someone can help on migrating the scripts to git. Please see #442

commented

Thanks for the reply. I think I'm asking a different question. The question I have is: is there a reason this repo is waiting on CPython to fix things? I'm wondering if bugs could be fixed here first and make releases to pypi and let CPython catch up (or not) to this package.

commented

This repo only backports the fixes. It doesn't fix it here and make upstream PR. IIRC the repo started as a module and was added to stdlib so development happens upstream and then backported here. I am not sure having development here would be good since this could cause mismatch between upstream and this package. Also upstream has more reviewers from core team. Getting backport machinery working would help this repo.

commented

@rsyring - so, I think this repo has a potted history, given its place as a port of the original repo from before Mock became part of the standard library. With hindsight, I would have argued to keep Mock out of the standard library for exactly the reasons you describe: CPython releases at a glacial pace, and for very good reasons.

However, we are where we are. Given the scarcity of maintenance for Mock in the first place, splitting that effort into two by having feature development take place in two repos seems like a bad idea.

So, as things stand, CPython is the only place that development should take place with this repo now strictly being for a backport. The trouble is that the "backporting" bit is currently broken. If we can get that working seamlessly (oh for @Mariatta to write us a bot as amazing as the CPython ones...), then cranking out new backport releases could happen much more quickly...

"closing" this issue, but please don't take that as a sign that discussion should stop.

commented

@cjw296 sorry just got to reading this message now. Let me know what are your needs about backporting bot, if you have specs/expectation, that would be great. Not sure where the discussion should live.
I'm also working on the backport bot for aiohttp project, so knowing more about what you need for this (or other) project will be useful.
Thanks.

commented

@Mariatta - no worries, I think we're all good. The process is documented here:
https://mock.readthedocs.io/en/latest/#backporting-process

Unfortunately, the chances of patches not applying are high enough that I suspect it's not worth trying to automate that...

commented

Mariatta was mentioned, but she's out of open source from March 18th to May 9th, 2019 . Be aware she might not get to this until after PyCon US.
(I'm a bot)