On Sun, 2016-09-11 at 17:30 +0200, Timm Bäder wrote:
On 10.09, Evan Nemerson wrote:This is something I've been thinking about lately, too. We currently rely on Jürg and Luca's expertise pretty heavily for development and patch review, and since they are both busy with other stuff Vala development has slowed down quite a bit. Assuming we can't organize financing to pay Jürg and/or Luca to work on Vala, I think we need to focus on a more decentralized development approach where we rely more on contributions from people with less expertise with the Vala internals.I agree that a more decentralized approach would be better, but as I said that can't possibly happen if nobody ever even tries to work with valac internals. 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.
I'm not trying to say nobody should try to work on the internals; quite the opposite. I'm saying we need to make it easier to do so. Even patches that look obviously correct on the surface can have unintended side-effects which break things is unexpected ways, especially for people who aren't extremely familiar with the code. We currently rely pretty heavily on expert knowledge when looking at patches to make sure they don't have unintended side-effects, which means a fairly deep knowledge of valac's internals is required for reviewing patches. Unfortunately, the only way to gain that knowledge is to work on valac and have patches reviewed, so we end up with a bit of a chicken-and-egg problem. For a lot of patches we can use testing as an additional check to make sure the patch doesn't break anything. With that in place, the bar for trusting reviewers is significantly lower, to the point where people who are less familiar with the valac internals could do reviews for a lot more patches, and Jürg and Luca needn't be bothered for most issues. Think of it as a way to build up the trustworthiness of a patch. In order to be included in valac, a patch needs a certain level of trust. Code reviews each build up a bit of trust, and the more expertise the reviewer has with the vala internals the greater the weight of each review. Passing automated tests also boosts the level of trust in a patch; the better the automated tests, the more trust we start with, and the less we need to add to get it to the point where we trust it enough to get it in the compiler.
<snip, rest of the mail>I assume "more testing" is basically interesting because we need less (sophisticated) review? That might be true from a functionality POV but not regarding architecture etc. But more tests are always good of course.
I certainly wouldn't think of it as a less sophisticated review process. If anything, I think it's more sophisticated. I would say it's interesting because it would let us accept patches when the reviewers have less expertise in valac itself, because at least we know the patch doesn't break everything. Obviously automated testing can't replace humans entirely. We would still need human reviewers, and big architectural changes would still require feedback from people like Jürg and Luca, but not all patches would. If we don't have to bother them with the little stuff development can move a lot faster, and when something big comes up *then* we can pull them in. Both of them are still (AFAIK) available for the occasional review, they just don't have the same amount of time for such reviews they once did. While solid tests may not be as helpful for deciding if major architectural changes provide a net gain, they are critical for actually writing them. In a large project like valac, even if they're made by someone with a lot of expertise in the internals major changes are very likely to break something. A comprehensive test suite lets us be much more confident in changes like that, so the question becomes whether or not we want the change, not whether making it will break everything. It's also worth noting that getting patches merged also means people are going to be more likely to contribute again, and as more of their patches are merged and they work on the compiler more the level of trust the community has in them will likely grow, and their patch reviews will carry more weight. Eventually, that list of two people I consider to really be experts in vala's internals may grow. Evan
Attachment:
signature.asc
Description: This is a digitally signed message part