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