--- wikisrc/kyua/import.mdwn 2012/09/01 19:58:18 1.3
+++ wikisrc/kyua/import.mdwn 2012/09/01 20:25:06 1.4
@@ -2,7 +2,7 @@
[[!toc levels=2]]
**Project owner: [Julio Merino](mailto:jmmv@NetBSD.org).**
-**Status: draft as of 2012-08-31; not even sent for review yet.**
+**Status: under review by tech-userlevel@ as of 2012-09-01.**
The import of Kyua into NetBSD to replace the deprecated ATF tools is
planned to happen in NetBSD 7.0. The ATF libraries will remain in place,
@@ -114,8 +114,7 @@ hacking, in this case), take the estimat
## Discuss this plan in tech-userlevel@
If you are here it's possibly because a review request for this plan has
-already been published and thus the plan has already begun. If
-not... well, hold off for a little bit ;-)
+already been published and thus the plan has already begun.
This plan will be sent to the tech-userlevel@ mailing list asking for
comments. **Two weeks shall be allowed for initial discussion.** Depending
@@ -136,6 +135,9 @@ If core@ approves the plan, the next ste
core@ disagrees, core@ will be asked to provide advice on the corrections
that should be made before the plan can be approved.
+It is hard to tell how long this step will last, but possibly account for 2
+to 4 weeks.
+
## Import Kyua into src
As the [[introductory page to Kyua|/kyua]] describes, Kyua has been
@@ -218,12 +220,19 @@ easier than the original import describe
possible to cherry-pick any external changes into the tree without a
reimport (as has often been done in ATF).
+This step can take a few weeks of time, mostly due to the back and forth
+between different people in different timezones.
+
## User validation period
At this stage, **at least one month shall be given to the community** to
test the new tools and the new test results dashboards. Collect feedback
and address requests as appropriate.
+*Because the old `atf-run` and `atf-report` tools have not yet been dropped
+at this point, we can spend as much time as necessary on this phase to get
+things right.*
+
## Replace atf-run and atf-report with kyua-atf-compat
Import the Kyua-based `atf-run` and `atf-report` compatibility tools and
@@ -295,8 +304,8 @@ First of all, why did I use C++? To mak
safer (the RAII programming pattern is really useful in avoiding memory and
resource leaks with minimal effort). And C++ is part of the base system
and a supported language, so there was no reason not to do so. But that's
-not the point of this item: if you don't like C++, this is not going to
-convince you otherwise.
+not the point of this item: if you dislike like C++, this is not going to
+make you think I did right.
It's true that, if we count the number of lines, Kyua brings in more C++
code than what will eventually be dropped by the removal of the ATF tools.
@@ -308,16 +317,17 @@ use, or will soon use, C++ in their code
be able to remove all C++ support from base anytime soon due to this, while
at the same time keeping support for all the ports that NetBSD has.
-Long term, if the use of C++ proves to be a problem, there are a few things
-that can be done to slowly get rid of it that have been floating my mind
-recently. The first is the rewrite of the performance-critical parts of
-Kyua in plain C. This would involve splitting the runtime engine of a
-single test case in its own binary (which, for other reasons may be a good
-idea on its own). The second is the rewrite of most user-interface code in
-Lua, which in itself would bring some extensibility advantages to the
-program. Both options will be investigated when the time permits. In the
-meantime, the replacement of ATF with Kyua does not make things worse; it
-just changes one chunk of code with another.
+Long term, if the use of C++ proves to be a problem, there are a couple of
+major things that can be done to slowly get rid of C++. These ideas have
+merits of their own (not only remove C++). The first is to split the
+execution engine of a single test case into a separate binary and, because
+this would be performance-critical, write it in plain C. The second is the
+rewrite of most user-interface code in Lua, which in itself would bring
+some extensibility advantages to the program; I haven't pursued this yet
+because my knowledge of Lua is very limited. Both options will be
+investigated separtely when the time permits. In the meantime, the
+replacement of ATF with Kyua does not make things worse; it just changes
+one chunk of code with another.
## No need for Lutok as a public library