GNOME.org
 

Re: [Vala] The future of Vala

some killer apps may be a good AD.

2016-09-12 0:51 GMT+08:00 Evan Nemerson <evan 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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]