some killer apps may be a good AD.
2016-09-12 0:51 GMT+08:00 Evan Nemerson <e...@coeus-group.com>: > 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 > _______________________________________________ > vala-list mailing list > vala-list@gnome.org > https://mail.gnome.org/mailman/listinfo/vala-list > _______________________________________________ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
