User tests: Successful: Unsuccessful:
Fixes all the useless issues that were created. It was quicker to fix than to post 30 issues.
PS as I have said before and put on the road to beta issue #27812 there needs to be a policy and procedure for this
Pull Request for Issue # far too many to list .
Status | New | ⇒ | Pending |
Category | ⇒ | NPM Change |
if you can't trust the upstream maintainer.
Then we should not be using their code
Then we should not be using their code
true
@brianteeman I'm creating issues to make a point. I've said several times this task should not be done manually and instead a bot should check daily for outdated deps and create a PR. The PR can then be tested, just like it would be human created PR.
The use of a bot was somewhat frowned upon, yet nobody bothers to update these dependencies.
Which is why I put it on the Road to Beta issue
Yes, over 3 months ago, yet nothing has been done about it and you wouldn't have needed to create this PR
Only takes one of the maintainers a minute to activate a bot on the repo.
Doesn't solve the problem that testers doesn't know what to test.
We have to accept that not every issue can be tested by everyone
Doesn't solve the problem that testers doesn't know what to test.
Well what about adding a bot comment by the issue tracker that adds that test instructions?
Ah ok. :-)
A bot wouldn't write test instructions either
Our bot can check what package is updated and than throw in some default test instructions. Sure it cant parse the change log etc but some basic test instructions can be generated when this is the only concern regarding not using the auto update bot.
In the end an maintainer has to take a look into the PR anyway. So when there is something special to test in the change log that can be raised and moved back to pending.
Closing as by the time someone looks at it it will be out of date
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-05-17 08:12:46 |
Closed_By | ⇒ | brianteeman | |
Labels |
Added:
NPM Resource Changed
?
|
Creating the PR is not the problem you should also write a proper testing description and at least check the release notes of the upstream packages for any b/c
looking at https://jquery.com/upgrade-guide/3.5/ you there some.
Many upstream packages (doesn't matter if composer or npm) doesn't follow semver or as bad as we sometimes on b/c breaks. So doing a code review is often the first thing to do if you can't trust the upstream maintainer.