We had an (experimental) Google Hangout meeting with some core developers today - here are the notes I took, completely unedited because I want to go to sleep ;)
If I missed or misrepresented something, please let me know - sorry! pytest hangout meeting ====================== people ------ - Bruno/nicoddemus - Holger/hpk - Florian/The-Compiler - Floris/flub - abusalimov (pytest-catchlog contributor) - Ronny/ronny ronny: meta-organization ------------------------ ronny proposes to have a meta-organization to have an issue tracker and wiki to collect tasks/informations involving more than one pytest-dev project. Something similar to metaflask. Meta-things like how pytest-dev work, how to release those, etc. Also collect infos about the members of the project. -> Task workflow for management tasks which would feel clunky on a ML https://github.com/pocoo/metaflask Bruno sees some value as there's a plugin index thing there. flub asks if this isn't basically the same than using a prefix on PyPI. ronny/bruno: There's much more information than you could have on PyPI, you could add information like compatibility etc. flub: Let's try it - worried that it's another data source to get out of data ronny: We should re-evaluate it in 6-12 months and see how well it worked. hpk: plugincompat is already there and interesting - why not just add a 'people' page on the website? flo: I think having a machine-readable represenation of plugins and people doesn't make sense, even metaflask is a graveyard. flub: We already have an overview of recommended plugins in the docs, as for logging, just let's clarify there. ronny: but what about cross-project issues, I don't want those in the pytest tracker. e.g. a plugin moving to github. I'd like to see a separate bug tracker for ecosystem tasks. hpk: Why not just a 'cross' label for pytest issues. I don't think it's worth it to have a repo just for issue tracking? The issues also are more visibile like currently. flo: I don't see why pytest (as an ecosystem) is concerned about other projects moving. bruno: Other than movements, what do you think should be there? ronny: e.g. maintainer applications or moving to pytest-dev? hpk: I think that's fine on the mailinglist (flo points out it's documented that way already) ronny: okay, let's do labels for issues then and use the ML for other stuff. hpk: sprint ----------- What about a pytest sprint in spring and doing crowd-funding for travel? ronny: he'd like to ask one of the Plone maintainers who's interested in pytest and experienced in setting up those sprints. everyone likes the idea! ronny: moving other projects to github -------------------------------------- ronny is currently working on a better import from bitbucket to github. ronny would like to migrate stuff from bb to gh flub: the maintainer of that would definitely need to agree, ronny agrees. -> move every project where the maintainers agree to github ronny: automated releases ------------------------- ronny: pushing signed tag to github -> get release uploaded to PyPI hpk: that's the golden aim, but regendoc is still not completely automated. ronny: I want to work on that, with Travis creating a PR every time something changes via regendoc. florian/ronny: Only signed tags should cause releases! hpk: I'm still very sceptical about that - it often takes a couple of tries to release something. ronny: but you can create rc tags, etc. etc. until things look right. hpk: I like to create an artefact, test that, and release *exactly that*. With a tag workflow you lose that ability. ronny: But it would with reducable builds. The build system should create the same artefact. hpk: Let's do a PR against howtorelease. I want an automated process, I just don't think tagging is the right way to do that. -> The work is a good idea either way, no matter whether we trigger the process via tags or another mechanism. bruno: At work we create a release branch, that branch generates artefacts which aren't published yet. I can *manually* publish and tag it then. flo: I'd like it most if *testing* was automated. bruno: What about using devpi via travis? ronny: We could have a release branch and then make travis do something different there. general idea: PR -> release branch -> travis uploads a release somewhere and tests it -> you can publish that artifact holger: I'm doing releases for 7-8 projects - we do want to be sure wheels are working properly. wheels already were broken earlier. flub: But that works already with an option? I manually build with setup.py and use tox to test those? ==> we can all agree on automating steps and the general idea holger: other issues are the changelog or merging features/master. Usually when I merge something into master I merge it into features as well. holger: What about doing auto-merges via bot of master -> features flo: I think this is too noisy, what about weekly or so? holger: We don't really have a way to do this systematically so far. bruno: Why not just before every master/bugfix release? If we fix a bug we'll do a release anyways, so why not do it then? (holger leaves) ronny: subtests --------------- new concept introduced to unittest.py with py3 - you can have sub-tests which means the test still continues when an assertion fails. this would allow to create "sections" with proper names (and reporting) for larger tests. flub: So what's the challenge about that? [I couldn't really follow, so no logs here, sorry] ronny: capturing ---------------- ronny: We currently replace sys.std... objects and replace them by capturing ones. I'd like to add a kind of capturing where the capturing captures the whole test run. [I couldn't really follow, so no logs here, sorry] --> let's move it to the ML because it's better when written deferred until later -------------------- - unittests in pytest testsuite - DI framework - 3.x plans -- Florian -- http://www.the-compiler.org | [email protected] (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/
signature.asc
Description: Digital signature
_______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
