We could add a script in each repo that takes the latest pytest version and updates the relevant config, then use asottile all-repos to run those scripts with any new versions
On Wed, Jul 29, 2020, 11:23 Jim Brännlund <jimbrannl...@fastmail.com> wrote: > I’m not sure Travis supports (or allows it for free tier) scheduled runs. > > But I do agree it would be the best way to at least mitigate the risk of > zero-day bugs. > On 29 Jul 2020, 11:44 +0200, Sorin Sbarnea , wrote: > > Apparently release 6.0.0 managed to uncover what I was afraid it would do: > breaking not actively maintained plugins. It was a small issue, but enough > to cause breakages and chain of dependency pinning for the users. > > There was nothing wrong with pytest release process, there was a > pre-release and also enough time to raise bugs... only if someone would try > that pre-release before the release was made. Experience told me that less > than 1/1000 users will try it. > > Can someone help me bring pytest-html plugin to actively maintained status? > https://github.com/pytest-dev/pytest-html/issues/318 > > > For me actively maintained does means it has CI/CD jobs that run scheduled > and that also tests unreleased versions of its main dependencies, in that > case this means at least "pytest" (and likely ansi2html too). I used this > approach with several projects in order to avoid day-zero outages when one > dependency makes a new release. > > That issue also made me discover that there is a gap between the > guidelines from > https://github.com/pytest-dev/pytest/blob/master/CONTRIBUTING.rst#submitting-plugins-to-pytest-dev > and the reality. > > An external contributor is not able to @mention a maintenance team (in > fact no proofs that it even exists) so PRs may be lingering for a while or > ever without knowing who could be able to help moving them. Only practical > solution I found so far was to dig the commit history and make guesses who > is likely to be a core, dig for his online contacts and hope he receives > your call and happens to be available or willing to help. > > Sadly is a gambling most of us already do all the day and I am not sure > how it can be improved. This should not be ignored because most occasional > contributors are never going to try to contribute again if their initial > work is not reviewed, making maintenance even harder. > > > While I am trying to sort the pytest-html issue right now, I do have few > more generic questions: > > How are users expected to contact those with power of making a change on > any project under pytest-dev organization? > > Is this mailinglist the only option? > > I personally dislike mailing lists and avoid them. I find them as a > communication barrier to occasional contributions. You can only post to > them if you subscribe, no way to reply to a thread if you were not > subscribed when original message was posted. > > Why not an online forum, where anyone can do a social login and post a > message/reply or watch a specific topic he is interested in, without having > to expose his email and subscribe to far more than he may want? Two easy > alternatives are either Github discussions (beta opt-in, can provide > details) or just using https://discuss.python.org/ -- where we could use > a category or tag, which both can allow subscript, in addition to topic > subscription. > > > I do have a lot of admiration for pytest ecosystem in general and more > than happy to help it grow. > > Cheers > Sorin Sbarnea > > > > _______________________________________________ > pytest-dev mailing list > pytest-dev@python.org > https://mail.python.org/mailman/listinfo/pytest-dev > > _______________________________________________ > pytest-dev mailing list > pytest-dev@python.org > https://mail.python.org/mailman/listinfo/pytest-dev >
_______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
