Re: [Vala] The future of Vala

[Timm Bäder]

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

Re: [Vala] The future of Vala

[Timm Bäder]

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

[Vala] The future of Vala

[Timm Bäder]

Hey,

this is probably just a mail for Jürg and maybe Luca, but if you have a
relevant opinion on the matter, that might be a fine reply as well.

So, for quite a while the Vala project has seen very little activity.
The three people most involved (Jürg, Luca and Flo) are barely on IRC
and/or otherwise reachable which makes it hard to get an opinion or info
from them. On the other hand, some people are still doing a great job,
namely Rico with all the binding work, as well as Evan (I haven't kept
up with what Al is doing other than replying to bugzilla issues that
won't be fixed unless it's a binding issue).

Lots of people are worried about how the project will stay alive (or
if), and quite a lot of projects are written in Vala (including one I
maintain) -- and people keep porting projects from C to Vala, mostly
hoping for more contributions, hoping the Vala's C#-like syntax scares
off less people.

Now, we all know that Vala has enough bugs that need to get fixed, as
well as lots of potential for improvements (I'll just disregard all the
wishes for special syntax for fringe features on IRC, that's not what
I'm talking about). Some of them are easy to fix but even if the patches
are present in bugzilla and their author is willing to fix them after
a review, the review just never happens. This doesn't just cause those
bugs to stay unfixed, but those people will also never get accustomed
to the internals of valac and so they will never work on anything more
important than this simple fix.

I have tried in the past to do exactly that and post some patches for
simple fixes to get an understanding of valac internals but it's quite
frankly huge and there's not a real high-level documentation one could
work with (apart from a few very old blog posts form Luca) and neither
working tools do debug it (I've once spent a few hours on fixing valag
but then gave up...).


So... what's the deal here? Is there any way forward one could look
into? Is it wip/transform? IIRC there was some dbus stuff broken here?
Are there any TODO items for cleaning up the compiler? Should we just
tell people to not use Vala in the first place (which would be better
for the in the long run)? All of these are fine, but the current
situation not so much.


Sincerely,
Timm
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list