Hi!
I am proposing to move all the content away from qa.php.net and merge it
into php.net
These are the follogwing things currently on the side:
-
Documentation on how to write tests
(https://qa.php.net/write-test.php), and how to handle bug reports
(https://qa.php.net/handling-bugs.php); which should be integrated in
wherever we now have internals documentation — please advise where
that should go. -
Some goals of the QA team (https://qa.php.net/projects.php), which we
can probably remove. -
The latest QA releases (https://qa.php.net/), with SHAs; this should
be merged with https://www.php.net/downloads in some fashion. It would
also mean that release managers won't have to update two git
repositories. -
A whole lot of "make test" reports, last really used in 2017 for PHP
7.1: https://qa.php.net/pftt.php — none of the links to the actual
reports work any way. This also takes up nearly 70GB! of data. I
recommend we just delete it all.
Opinions?
cheers,
Derick
I am proposing to move all the content away from qa.php.net and merge it
into php.net
Generally +1 on this.
- Documentation on how to write tests
(https://qa.php.net/write-test.php), and how to handle bug reports
(https://qa.php.net/handling-bugs.php); which should be integrated in
wherever we now have internals documentation — please advise where
that should go.
write-test.php is important, and https://qa.php.net/phpt_details.php
maybe even more so. As this is relevant for run-tests.php (I don't
think there are still alternative test runners), php-src/docs seems to
be a good home for it.
handling-bugs.php needs a thorough overhaul, or might be dropped
altogether. Some of the quickfix snippets might still be useful for the
GH issue tracker, though.
- A whole lot of "make test" reports, last really used in 2017 for PHP
7.1: https://qa.php.net/pftt.php — none of the links to the actual
reports work any way. This also takes up nearly 70GB! of data. I
recommend we just delete it all.
The PFTT reports have always been pretty much useless.
https://qa.php.net/reports/run_tests.php had some value, but
apparently the SQLite DB had been corrupted again, so this can probably
be removed as well. I believe the functionality to send these reports
has been dropped from run-tests.php quite a while ago anyway.
Christoph
- Documentation on how to write tests
(https://qa.php.net/write-test.php), and how to handle bug reports
(https://qa.php.net/handling-bugs.php); which should be integrated
in wherever we now have internals documentation — please advise
where that should go.write-test.php is important, and https://qa.php.net/phpt_details.php
maybe even more so. As this is relevant for run-tests.php (I don't
think there are still alternative test runners), php-src/docs seems to
be a good home for it.
I agree, it should go there. All the "read me" type docs are MD, but the
actual documentation in
https://github.com/php/php-src/tree/master/docs/source is (for good
reasons) in RST. I think it makes sense for the PHPT documentation
(write-test.php and phpt_details) to be a single ".md" in docs/ — one
explains the how and minimal how, whereas the latter is much more
detail).
handling-bugs.php needs a thorough overhaul, or might be dropped
altogether. Some of the quickfix snippets might still be useful for
the GH issue tracker, though.
I say we just drop it.
- A whole lot of "make test" reports, last really used in 2017 for
PHP 7.1: https://qa.php.net/pftt.php — none of the links to the
actual reports work any way. This also takes up nearly 70GB! of
data. I recommend we just delete it all.The PFTT reports have always been pretty much useless.
https://qa.php.net/reports/run_tests.php had some value, but
apparently the SQLite DB had been corrupted again, so this can
probably be removed as well. I believe the functionality to send
these reports has been dropped from run-tests.php quite a while ago
anyway.
I tried to see what was going on there, but on the command line, the
8.2.18 file is fine (there is a file for every version). It's just an
empty database and the "reports" table doesn't exist.
I have now removed the empty files, so the report works.
But I wouldn't say it's useful.
cheers,
Derick
write-test.php is important, and https://qa.php.net/phpt_details.php
maybe even more so. As this is relevant for run-tests.php (I don't
think there are still alternative test runners), php-src/docs seems to
be a good home for it.I agree, it should go there. All the "read me" type docs are MD, but the
actual documentation in
https://github.com/php/php-src/tree/master/docs/source is (for good
reasons) in RST. I think it makes sense for the PHPT documentation
(write-test.php and phpt_details) to be a single ".md" in docs/ — one
explains the how and minimal how, whereas the latter is much more
detail).
I had already submitted PR #15939 before I read your reply, but I'm more
than fine going with PR #15940 instead.
handling-bugs.php needs a thorough overhaul, or might be dropped
altogether. Some of the quickfix snippets might still be useful for
the GH issue tracker, though.I say we just drop it.
Okay.
The PFTT reports have always been pretty much useless.
https://qa.php.net/reports/run_tests.php had some value, but
apparently the SQLite DB had been corrupted again, so this can
probably be removed as well. I believe the functionality to send
these reports has been dropped from run-tests.php quite a while ago
anyway.I tried to see what was going on there, but on the command line, the
8.2.18 file is fine (there is a file for every version). It's just an
empty database and the "reports" table doesn't exist.I have now removed the empty files, so the report works.
But I wouldn't say it's useful.
I agree that it is preferable to have users open tickets on GH about
failing tests; at least you can request feedback there.
Christoph
Hi!
I am proposing to move all the content away from qa.php.net and merge it
into php.netThese are the follogwing things currently on the side:
Documentation on how to write tests
(https://qa.php.net/write-test.php), and how to handle bug reports
(https://qa.php.net/handling-bugs.php); which should be integrated in
wherever we now have internals documentation — please advise where
that should go.Some goals of the QA team (https://qa.php.net/projects.php), which we
can probably remove.The latest QA releases (https://qa.php.net/), with SHAs; this should
be merged with https://www.php.net/downloads in some fashion. It would
also mean that release managers won't have to update two git
repositories.A whole lot of "make test" reports, last really used in 2017 for PHP
7.1: https://qa.php.net/pftt.php — none of the links to the actual
reports work any way. This also takes up nearly 70GB! of data. I
recommend we just delete it all.Opinions?
cheers,
Derick
I mainly just reference https://qa.php.net/expectf_details.php. I also link
to this from https://github.com/ScriptFUSION/Pip. Keep in mind that PHPUnit
(secretly) supports the PHPT format and the QA site is the only
(un)official reference for its implementation.
I think the QA subsite should be retired as it is very difficult to
discover and accessing the PHPT information is currently somewhat of a dark
art. It should not be hidden. But will the old links still work (read:
redirect) to the new location?
Cheers,
Bilge
I mainly just reference https://qa.php.net/expectf_details.php. I also link
to this from https://github.com/ScriptFUSION/Pip. Keep in mind that PHPUnit
(secretly) supports the PHPT format and the QA site is the only
(un)official reference for its implementation.
Oh, I thought that had been removed from PHPUnit some time ago;
apparently, it has not.
I think the QA subsite should be retired as it is very difficult to
discover and accessing the PHPT information is currently somewhat of a dark
art. It should not be hidden. But will the old links still work (read:
redirect) to the new location?
Maybe for some time a 308 Permanent Redirect might be a good idea.
Christoph
Maybe for some time a 308 Permanent Redirect might be a good idea.
I don't think there's any reason to qualify with "for some time"; the
redirect is just as likely to be useful in 10 years time as 10 weeks.
(Sadly, the idea of a permanent redirect causing a source page to
rewrite itself has never caught on, outside of search engine indexes.)
Luckily, redirects are cheap: point qa.php.net at the same servers as
www.php.net, stick up a <VirtualHost> block with a handful of
RewriteRule or Redirect directives, and there's no on-going cost.
Obviously, at some point the redirects might get accidentally broken,
but they would also be easy to put back if somebody noticed.
--
Rowan Tommins
[IMSoP]