Re: [Vala] The future of Vala

[Al Thomas <astavale yahoo co uk>]

----- Original Message -----
> From: Timm Bäder <mail baedert org>
> Sent: Sunday, 11 September 2016, 16:30
> Subject: Re: [Vala] The future of Vala

> Basically, I'm not saying that Jürg or Luca need to
> even work on valac, but a patch review now and then would already help
> a lot. And some of those patches are really quite simple and obviously
> correct, but no review except theirs has any weight.


Anyone with GNOME commit access can add to the Vala repository.
So for these two recent patches, a positive review was given and
then the submitter committed their own patch:
https://bugzilla.gnome.org/show_bug.cgi?id=760436
https://bugzilla.gnome.org/show_bug.cgi?id=765785

The purpose of review is to challenge the assumptions of the submitter.
While a solution might be "simple and obviously correct" to the submitter
the reviewer needs to think outside the box and consider which circumstances
may cause problems. Reviews need to be critical, but also offer constructive
advice on improvement. It's developing that subjective idea of what is good quality
code for Vala that is the hard part in review.


> I assume "more testing" is basically interesting because we need less

> (sophisticated) review? 

I don't think they are distinct concepts. Testing is part of the review
process. We are talking regression tests here. Tests should not be testing implementation
details (the conceptual architecture) too rigidly, if at all, because that 

will limit innovation and refactoring in the code base. You may want some 

integration tests between the parsers and the AST for example, but to test
every function would be far too rigid. We're talking about code samples
that are run against valac to ensure that no regressions occur and the compiler
is running to spec. I'm hoping the valadate version will ultimately include
timings so we can start to identify slow points in the compiler as well.