[#12984] - Error in sr-YU installation ini file
- Fixed in Code Base
- 23 Nov 2016
- Medium
- Build: staging
- # 12984
- Diff
- infograf768:sr-YU_correction
- Success continuous-integration/drone the build was successful Details
- Success continuous-integration/travis-ci/pr The Travis CI build passed Details
User tests: Successful: Unsuccessful:
Corrected EOL and a wrong string.
Can be merged on review.
@Bakual
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Installation Language & Strings |
| Status | Pending | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-11-23 07:53:57 |
| Closed_By | ⇒ | Bakual |
| Labels |
Removed:
?
|
||
| Milestone |
Added: |
||
Only one string is changed !
The rest is EOL
The Serbian TT is OK!
Re: correction sr-YU ini installation file
Sent: 23 Nov 2016 08:42
From: cicans
Recipient: infograf768
Thank you JM I corrected this
@PhilETaylor Usually, they are commited directly by me, not even going though a PR. Apparently I have messed up a file and thus JM made a PR to correct it. All fine
We either have a policy of 2 successful tests of a PR - or we dont.
I guess we don't then.
Which is why we always get bitten in the arse.
We either have a policy of 2 successful tests of a PR - or we dont.
We do. But when the PR is obviously easy, maintainers sometimes merge on review.
This is just a string and EOL fix. Don't think we should waste time on testing it. Code is public.
But when the PR is obviously easy, maintainers sometimes merge on review.
Yes I have heard that before, do you really need me to dig out example after example where "PR is obviously easy" and where "maintainers sometimes merge on review" and when it has come back to bite us?...
Just making a point - but again no one can be bothered to improve processes or quality and so im falling on deaf ears again. and again.
We either have a policy of 2 successful tests of a PR - or we dont.
We don't have a policy of 2 successful tests at all. It's a rule of thumb, but for some PRs we expect more tests and some less (eg codestyle ones).
Installation language files always are commited directly, there never was an issue with that approach so far. Chance that something breaks here is slim anyway. It's only INI files
We don't have a policy of 2 successful tests at all.
And you dont see a problem here...
so im falling on deaf ears again. and again.
And you dont see a problem here...
No. Because it doesn't make sense to require two tests for a doc block change.
so im falling on deaf ears again. and again.
I hear you loud and clear and respect you very much, but I don't agree with your opinion in this case. That's not being deaf.
Really... that kind of language always gets us into trouble ;-)
Especially as there are 320 lines apparently modified in the PR...