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. _______________________________________________ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
