Re: [Vala] The future of Vala

[Timm Bäder <mail baedert org>]

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.