Re: [Vala] The future of Vala



On 11.09, Al Thomas wrote:
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

That's not interesting. In the scope of this thread I don't care about
bindings whatsoever; that is covered by Rico and Evan.


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.

Again, not the point.


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 

This thread is specifically about the inactivity of the two maintainers
of the compiler; I'd want someone with a good understanding of both the
fine-grained and the high-level concepts of valac to review the patches;
your testing doesn't help there. Which is why I asked Evan about the
purpose of the improved testing. Otherwise I don't see a strong reason
why more testing would attract more people to work on the compiler.

Since wip/transform exists and because that's generally how things work,
I also assume that the maintainers have some idea of where the project
should be heading and I don't want patches reviewed by other people to
later stand in the way of that direction.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]