Re: [Vala] The future of Vala

[bruce davidson]

Thanks for the frank discussion.

I read the stream, and it reveals some things about the Vala project 
that have been opaque. The actual decision about Vala's future pales in 
comparison to the path that got us here.


One of the reasons I chose Vala was it has the appearance of support 
from Gnome. I feel I can no longer depend on either that Gnome supports 
it, or that Gnome support is desirable.


The reason I decided against Ooc is that it's on hiatus. Now it turns 
out Vala has been on effective hiatus for a while. If I have to accept 
this for Vala, then I have to consider using Ooc. And if it's feature 
to feature, mano a mano, Ooc wins hands down.


So, this question strikes home: "Should we just tell people to not use 
Vala in the first place"


I wish you had.  I was going to put my  projects on hiatus until you 
made your decision on Vala's future. But I have no confidence that a 
decision will be made, and Vala will just continue languishing at Gnome.







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

Re: [Vala] The future of Vala

[Matthias Berndt]

Hey Al,

> Hmm, that seems a little unfair. You submitted the patch on the 08 Aug 2016 
> and it was reviewed on the 10 Aug 2016. Unfortunately your first version of 
> the patch included a bug that the review identified.
Well, I fixed that bug within a day. Then it took another 12 days for Jürg to 
ask another question, which I responded to within 15 Minutes. Then it took 
another 3 weeks for Jürg to respond to that. Now, I totally sympathise with 
Jürg, most people don't have as much time to work on their leisure projects as 
they would like. But please put yourself in my shoes as somebody who's trying 
to get his feet wet hacking on the Vala compiler. I mean, this is not a 
rewrite-the-world patch, the actual patch is -12/+7 lines. If that takes, say, 
six weeks to get merged, how long will it take to get a sufficient number of 
patches merged to build enough trust to get commit access? How long will it 
take to get a new feature merged, one that might be a couple hundred lines long 
or something? Again, I sympathise with Jürg and his lack of time. But 
nevertheless these long response times do not send the right signals to new 
compiler hackers.

> I would accept there is a communication failure of the Vala release cycle, 
> but I think there is a far more favourable interpretation of the decision not 
> to merge the patch at the current time. 
> 
> 
> Vala is a GNOME core project and currently follows the GNOME release cycle. 
> See 
> https://wiki.gnome.org/ThreePointTwentyoneA hard code freeze started on the 
> 12 Sep 2016 and you will see Vala 0.33.1 was tagged on that day. Including a 
> version of Vala with GNOME 3.22.0 that cannot build some packages just isn't 
> going to happen. I would say that is why your patch wasn't merged at the time.
OK, I didn't understand that. I'm happy that it now looks as though the patch 
will be merged soonishly.

> BTW, thank you for your work on Vala. It looks like you have four patches in 
> this next release. For anyone else who wants to see what Mattias's work has 
> improved in the type system of Vala's internals see:
> 
> https://git.gnome.org/browse/vala/log/?qt=author=matthias%20berndt
Perhaps you're right, maybe I should just be happy about the two bugfixes I 
already got merged :-)

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

Re: [Vala] The future of Vala

[Al Thomas]

> - Original Message -
> From: jezra <je...@jezra.net>
> Sent: Wednesday, 14 September 2016, 17:41
> Subject: Re: [Vala] The future of Vala

> For me as a vala user, the biggest frustration I have, and the
> number 1 reason I would NOT consider vala for a future programming
> project is the cumbersome documentation. For the future of vala, having
> usable documentation is an necessity. 

> In this regard, what can I do to help get the documentation to be
> usable?


Can you list some points on how it can be improved? The points can be specific
or a fanciful idea that could guide future requirements.


Anyone can have wiki access (it is MoinMoin). So if anyone wants to
update a code example or add new ones they just need to ask to get access.


Thanks,


Al
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] The future of Vala

[jezra]

> 
> Hi!
> 
> At first I didn't want to enter this discussion, because it targeted
> certain people, the Vala programmers, and I am not a programmer.
> 
>

I'm with you. Although I don't work on vala, I certainly work with
vala, and just yesterday I compiled one of my vala projects on the $9
CHIP computer and I couldn't be more pleased with the ease. 

For me as a vala user, the biggest frustration I have, and the
number 1 reason I would NOT consider vala for a future programming
project is the cumbersome documentation. For the future of vala, having
usable documentation is an necessity. 

In this regard, what can I do to help get the documentation to be
usable?

jezra
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] The future of Vala

[Dmitry Golovin]

08.09.2016, 20:33, "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

Hi!

At first I didn't want to enter this discussion, because it targeted certain 
people, the Vala programmers, and I am not a programmer.

I use Vala in my own projects as well as in company's projects just because I 
have free choice of programming language and I like Vala, so why not? 

It would be very sad if Vala stopped being supported, but I don't think it 
would ever happen because a lot of GNOME applications are written in Vala, and 
now we also have elementaryOS and Budgie Desktop.

I really like Vala because it is designed to be cross-platform, but unlike Java 
or C# it is "write once, compile anywhere". I really like the simplicity of 
Vala and the fact that it did replace Mono at least for some users.

Vala is good for writing desktop apps with the best GTK+ bindings so far, Vala 
compete for server-side web with Valum, Vala can also handle client-side web 
with caja, Vala is suitable for embedded programming with posixvala, Vala is 
even okay for microcontrollers with avr-vala. I don't really know how abandoned 
the listed projects are, but the idea is very good.

What I'd like to see is more platforms support: Android, iOS, web-browser. I 
know that there is GLib port for Android, so it should not be a problem to 
support this platform, I remember there was a cross-compilation success story 
from 2013. There should also be a iOS port, I even remember seeing valac 0.15 
compiled for iOS. The browser should be a problem because GLib does not work 
with Emscripten, don't really know about WebAssembly.

The other thing that is missing is a place with good code examples. There are 
few examples on GNOME Wiki (some of them are pretty outdated), there are very 
nice Cairo drawing examples in related documentation, but if you want something 
else, you just search for code in real projects (usually GNOME apps). There 
should be a website with collection of all possible Vala examples that 
encourages more people to use Vala and has a StackOverflow-style forum. 

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

Re: [Vala] The future of Vala

[Guillaume Poirier-Morency]

Hi,

I've been playing with Vala for about two years or so and like very much
what I can do with it.

I have to agree with Matthias: improvement and correctness go over
backward-compatibility at this stage. It's perfectly fine to use a specific
compiler version to build broken software and disting C sources to avoid
the mess.

Personally, I would really get more involved in the language and learning
its internals is one of my goal. I will still be using Vala for at least
the coming years by shaping my master around it.

To get more contributors, there's a couple of things that we should do:

   -  automate tests via some CI and check submitted patches
   -  more tests
   -  publish coverage reports to guide efforts

There's a lot of potential of getting people learning and contributing to
the core if we let them submit tests.

I managed to get *official* support for Vala from Codecov
https://codecov.io/. While it's a not a FOSS platform, they pretty much
only run gcovr/lcov and generate user-friendly reports. It would be a nice
way of covering the last point.

Also we have to be realistic: Vala is amazing when it comes to writing
software that integrates with GLib and we have to focus on the quality of
the C code generation. Outside that scope, the ground is already taken by
other languages.

I like the idea of using Vala for Web applications as the languages provide
a lot of features that are perfectly designed for that purpose. If I can
get Valum anywhere, I'm pretty sure that it could attract a lot of interest.

Thanks Jürg and Luca for the hard work, I think everyone here really
appreciate what you have done and how you've led the project so far.

2016-09-13 18:07 GMT-04:00 Matthias Berndt :

>
> Hey,
>
> > With Luca leaving the project ([Vala] Leaving the project <
> https://mail.gnome.org/archives/vala-devel-list/2016-
> September/msg0.html>), the situation is now even more
> > critical. Given that Joerg obviously has no time or interest it
> basically means that there
> > is no-one left who used to help developing the core language.
> I'd actually be interested, and I have a few ideas for improvements.
> However, the main problem I see is that
> it's very hard to get patches merged or discuss technical issues with more
> experienced developers. And thus
> the vala project in its current form is unable to recruit new compiler
> maintainers. Questions or suggestions
> on vala-devel-list don't get answers and it's similar on the IRC channel.
> Worst of all, even small patches
> take ages to be reviewed, e. g. this one:
> https://bugzilla.gnome.org/show_bug.cgi?id=615830
> It's just very tiring when one's efforts are ignored for weeks and the
> general impression is that new
> developers are something the project doesn't give a tuppeny-cuss about…
> In addition to that, I also believe that Jürg's decision not to merge the
> patch is misguided. If clear and
> obvious bugs like that (short summary: the compiler accepts code such as
> List l = new ArrayList())
> are retained because of broken third-party projects (shotwell was
> mentioned), then it's impossible to move
> things forward. And guess what: open source developers do what they do
> because they do want to move things
> forward. And if they can't do it in vala, they'll soon find some other,
> more welcoming project. And while
> I understand the importance of backwards compatibility, I don't think it's
> as important for vala as it is for,
> say, the kernel. Unlike the kernel, one machine can easily run two
> different versions of the compiler
> simultaneously, and if the shotwell people want to compile old, broken
> code, I think it's entirely reasonable
> to expect them to keep an old, broken compiler version around to do so. Of
> course, the far more likely case is
> that they, like basically anyone else, actually *want* the compiler to
> tell them about their broken code so they
> can fix it! Not to mention all the other user who'd like to have this fix…
>
> Oh, Jürg, if you're reading this: I hope you don't take any of this
> personally.
>
>
> > The bindings is another situation, those are quite vivid, from what I
> can see.
> >
> > Some words on my personal situation: Although I have been inactive as
> well for
> > the past couple of years, I’m still willing to maintain the VAPIs I
> started or contributed a lot to
> > (i.e. linux, posix, alsa, netlink, etc.).
> > My pet project, the special-interest-middleware FSO – freesmartphone.org
>  – is very dependent
> > on Vala, I guess it is among the top 10 largest Vala projects and during
> the development I helped
> > Joerg getting a number of great Vala features in a solid state, such as
> coroutines, closures, async dbus, etc.
> > Alas, my knowledge of the compiler internals is zero. One reason why FSO
> has been stalling is that I'm unsure
> > about whether Vala is going anywhere towards a stable (with reasonably
> sane criteria of 

Re: [Vala] The future of Vala

[Matthias Berndt]

Hey,

> With Luca leaving the project ([Vala] Leaving the project 
> ),
>  the situation is now even more
> critical. Given that Joerg obviously has no time or interest it basically 
> means that there
> is no-one left who used to help developing the core language.
I'd actually be interested, and I have a few ideas for improvements. However, 
the main problem I see is that
it's very hard to get patches merged or discuss technical issues with more 
experienced developers. And thus
the vala project in its current form is unable to recruit new compiler 
maintainers. Questions or suggestions
on vala-devel-list don't get answers and it's similar on the IRC channel. Worst 
of all, even small patches 
take ages to be reviewed, e. g. this one:
https://bugzilla.gnome.org/show_bug.cgi?id=615830
It's just very tiring when one's efforts are ignored for weeks and the general 
impression is that new
developers are something the project doesn't give a tuppeny-cuss about…
In addition to that, I also believe that Jürg's decision not to merge the patch 
is misguided. If clear and
obvious bugs like that (short summary: the compiler accepts code such as 
List l = new ArrayList())
are retained because of broken third-party projects (shotwell was mentioned), 
then it's impossible to move
things forward. And guess what: open source developers do what they do because 
they do want to move things 
forward. And if they can't do it in vala, they'll soon find some other, more 
welcoming project. And while
I understand the importance of backwards compatibility, I don't think it's as 
important for vala as it is for,
say, the kernel. Unlike the kernel, one machine can easily run two different 
versions of the compiler 
simultaneously, and if the shotwell people want to compile old, broken code, I 
think it's entirely reasonable
to expect them to keep an old, broken compiler version around to do so. Of 
course, the far more likely case is
that they, like basically anyone else, actually *want* the compiler to tell 
them about their broken code so they
can fix it! Not to mention all the other user who'd like to have this fix…

Oh, Jürg, if you're reading this: I hope you don't take any of this personally. 


> The bindings is another situation, those are quite vivid, from what I can see.
> 
> Some words on my personal situation: Although I have been inactive as well for
> the past couple of years, I’m still willing to maintain the VAPIs I started 
> or contributed a lot to
> (i.e. linux, posix, alsa, netlink, etc.).
> My pet project, the special-interest-middleware FSO – freesmartphone.org 
>  – is very dependent
> on Vala, I guess it is among the top 10 largest Vala projects and during the 
> development I helped
> Joerg getting a number of great Vala features in a solid state, such as 
> coroutines, closures, async dbus, etc.
> Alas, my knowledge of the compiler internals is zero. One reason why FSO has 
> been stalling is that I'm unsure
> about whether Vala is going anywhere towards a stable (with reasonably sane 
> criteria of stableness) 1.0.
> I’m also the creator of numerous bug entries where Vala generates invalid C 
> code and the Vala programmer
> is scared with an incomprehensible gcc error message. As far as I can see 
> many of those are still open for a
> bunch of years now – which makes me feel somewhat pessimistic about the 
> future of Vala.
Well, given that the official maintainers are effectively inactive, the future 
of Vala is clearly what we
make of it! Have you ever thought about hacking the compiler? I didn't find it 
that hard on a technical level,
and I'd certainly answer any questions I can.

> I’d welcome advise from the father of Vala, Joerg (or anyone other with solid 
> knowledge of the core),
> to give us some direction. Would a redesign / rewrite be necessary to move 
> forward to an 1.0 or
> would refactoring the compiler be enough to lower the contribution barrier?
Well, it depends on where we want to take the language! I have a few fixes and 
features in mind that I'd like
to address, and I can go into more detail if anybody is interested. What is it 
that you would like to see?

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

Re: [Vala] The future of Vala

[Dr. Michael Lauer]

Hi folks,

it’s great to see this discussion finally moving – albeit somewhat late.

With Luca leaving the project ([Vala] Leaving the project 
),
 the situation is now even more
critical. Given that Joerg obviously has no time or interest it basically means 
that there
is no-one left who used to help developing the core language.

The bindings is another situation, those are quite vivid, from what I can see.

Some words on my personal situation: Although I have been inactive as well for
the past couple of years, I’m still willing to maintain the VAPIs I started or 
contributed a lot to
(i.e. linux, posix, alsa, netlink, etc.).
My pet project, the special-interest-middleware FSO – freesmartphone.org 
 – is very dependent
on Vala, I guess it is among the top 10 largest Vala projects and during the 
development I helped
Joerg getting a number of great Vala features in a solid state, such as 
coroutines, closures, async dbus, etc.
Alas, my knowledge of the compiler internals is zero. One reason why FSO has 
been stalling is that I'm unsure
about whether Vala is going anywhere towards a stable (with reasonably sane 
criteria of stableness) 1.0.

I’m also the creator of numerous bug entries where Vala generates invalid C 
code and the Vala programmer
is scared with an incomprehensible gcc error message. As far as I can see many 
of those are still open for a
bunch of years now – which makes me feel somewhat pessimistic about the future 
of Vala.

I’d welcome advise from the father of Vala, Joerg (or anyone other with solid 
knowledge of the core),
to give us some direction. Would a redesign / rewrite be necessary to move 
forward to an 1.0 or
would refactoring the compiler be enough to lower the contribution barrier?

Best regards,

:M:

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

Re: [Vala] The future of Vala

[Gilzad Hamuni]

I consider myself a Vala user and I'd also welcome a donate-button if it really 
helps the project.

Hadn't there been Vala, I most probably wouldn't get in touch with all the glib 
stuff as a developer.

C and CPP take too much effort to gain the same goals.
C# is beautiful but still wastes CPU time.
Vala is beautiful and native. 

For me Vala is currently the only way to write native applications across 
different platforms. Sure I'd use a chance to show some appreciation.

Greetings


> Gesendet: Dienstag, 13. September 2016 um 08:46 Uhr
> Von: Ulink <ul...@gmx.at>
> An: vala-list@gnome.org
> Betreff: Re: [Vala] The future of Vala
>
> Am 2016-09-13 um 02:10 schrieb Michael Gratton:
> > It really sounds like Vala needs some maintainers.
> 
> I think there are some Vala USERS out there, which are able and willing
> to help with some minor and/or simple tasks and don't know how. So the
> "heavy weights" like Jürg, Luca, Evan and the like can do the important
> stuff.
> 
> A list of such "simple and boring stuff" including a general description
> how to help may push Vala forward only in little steps, but remember:
> 1000*0.1% = 100% :-)
> 
> Another idea: What about a "donate" button somewhere? Vala saves much
> time when programming Gtk/GLib and time==money .
> 
> -- 
> Bernhard
> ___
> 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

Re: [Vala] The future of Vala

[Ulink]

Am 2016-09-13 um 02:10 schrieb Michael Gratton:
> It really sounds like Vala needs some maintainers.

I think there are some Vala USERS out there, which are able and willing
to help with some minor and/or simple tasks and don't know how. So the
"heavy weights" like Jürg, Luca, Evan and the like can do the important
stuff.

A list of such "simple and boring stuff" including a general description
how to help may push Vala forward only in little steps, but remember:
1000*0.1% = 100% :-)

Another idea: What about a "donate" button somewhere? Vala saves much
time when programming Gtk/GLib and time==money .

-- 
Bernhard
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] The future of Vala

[Michael Gratton]

On Fri, Sep 9, 2016 at 3:34 AM, Timm Bäder  wrote:

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.


I'd like to see Vala continue, it's IMHO the only reasonable way to 
write high-level apps in GObject, but I /am/ biased. :)


As people have pointed out, we can get patches landed, bindings are 
being updated, and we can respond and triage bugs, improve automated 
testing coverage and debate hosting choice of infrastructure, but none 
of that's going to be terribly useful unless significant new releases 
continue.


It really sounds like Vala needs some maintainers. Perhaps Jürg, Luca 
and Flo are still keen but too busy at the moment, perhaps someone else 
needs to step up. But either way there needs to be one or a few people 
with some idea of where they want Vala to go, who have the time to put 
in to make sure it starts heading in that direction. In the end, its 
the maintainers that would decide if things like wip/transform is the 
way to go or not.


//Mike

--
⊨ Michael Gratton, Percept Wrangler.
⚙ 


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

Re: [Vala] The future of Vala

[Michael Gratton]

On Tue, Sep 13, 2016 at 2:19 AM, oyster  wrote:

some killer apps may be a good AD.


Like these? 



;)

--
⊨ Michael Gratton, Percept Wrangler.
⚙ 


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

Re: [Vala] The future of Vala

[oyster]

some killer apps may be a good AD.

2016-09-12 0:51 GMT+08:00 Evan Nemerson :
> 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.
>
>> > 
>>
>> 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
>

Re: [Vala] The future of Vala

[Al Thomas]

- Original Message -
> From: Timm Bäder <m...@baedert.org>
> Sent: Sunday, 11 September 2016, 17:43
> Subject: Re: [Vala] The future of Vala

> On 11.09, Al Thomas wrote:
>> 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.


I chose one of each. One is a binding, one is a patch to vapigen. 

> This thread is specifically about the inactivity of the two maintainers

> of the compiler; 


Clearly for you it is, but other people have expressed concerns about
the "future of Vala" so it is important to demonstrate work on Vala goes on.

> 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.


That is a fair question. If someone is going to work on the internals should
they take account of the various *transformer.vala files, etc. from 
wip/transform?

If, however, you are implying you don't want your patches reviewed by others 
please 

let me know. I have just reviewed a couple of your patches and I understand you
have commit access. So I was expecting after comments were addressed you would 
commit.
I did not do the review because of this thread, I have had a note of those 
patches for some 

time because I try and value people's contributions. If you look at your IRC 
log you 

will see I pointed out about testing for code that shouldn't compile and 
shortly after
the invalid code test patch was committed.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] The future of Vala

[Evan Nemerson]

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.

> > 
> 
> 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

signature.asc
Description: This is a digitally signed message part
___
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 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

[Al Thomas]

- Original Message -
> From: Timm Bäder <m...@baedert.org>
> Sent: Sunday, 11 September 2016, 16:30
> Subject: Re: [Vala] The future of Vala

> 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

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.


> 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 

will limit innovation and refactoring in the code base. You may want some 

integration tests between the parsers and the AST for example, but to test
every function would be far too rigid. We're talking about code samples
that are run against valac to ensure that no regressions occur and the compiler
is running to spec. I'm hoping the valadate version will ultimately include
timings so we can start to identify slow points in the compiler as well.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] The future of Vala

[Dev_NIX]

+1

--

*   EOF   *

2016-09-10 22:44 GMT+02:00 Evan Nemerson :

> 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.  However, we obviously also need to
> keep the compiler's code quality as high as possible.  There are a lot
> of unreviewed patches rotting away on Bugzilla right now, and that's a
> tragic waste of effort.
>
> The answer, at least from my perspective, is to embrace automated
> testing.  We need to significantly beef up the tests shipped with the
> compiler (the ones `make test` runs) so we can check make sure patches
> don't break anything.  This, in turn, would allow people a bit less
> comfortable with the valac internals (such as myself) to review a lot
> more patches, and hopefully get development back up to a much higher
> rate.
>
> Chris Daley has been working on moving a version of Valadate into the
> Vala tree (see ) so tests are
> easier to write.  I'd like to get some feedback from people on his
> work, and if it would encourage people to write more tests we should
> merge it after 0.34 is branched.
>
> I'd also like to provide a robust way to have assorted projects written
> in Vala tested, which would be especially important for changes to
> bindings.  We already have this to some extent (see
> ), but there is no integration with Bugzilla
> and it's not very well maintained (many projects are broken due to non-
> Vala issues), and AFAIK the configuration isn't public so there is no
> way for people to help.
>
> There are a lot of great free CI services we can take advantage of to
> improve this, including (off the top of my head):
>
>  * Travis CI
>  * AppVeyor
>  * GitLab
>  * Snap CI
>  * Drone.io
>  * Semaphore
>
> We don't have to choose one; we can use multiple services (especially
> if AppVeyor is one of them).
>
> One major barrier here is Bugzilla.  I'm not really concerned with
> requiring people to sign up for an account, and I really like the
> workflow (especially with git-bz), but CI integration is a problem and
> I'm not sure how to resolve it.
>
> The obvious solution would be moving development to GitHub, but I'm
> certainly uneasy about depending on a proprietary platform, and I'd
> sure others would be as well.
>
> Perhaps a better option would be moving to GitLab, or installing a
> GitLab instance somewhere (possibly on the GNOME infrastructure?).
> AFAIK Travis only supports GitHub, but Travis isn't our only option.
> If it were up to me, I would probably move to GitLab.com.
>
> Once we have good automated testing support, a good code review tool
> would be extremely helpful.  If we stick with Bugzilla, I know it's
> possible to integrate Gerrit, though AFAIK it would require a plugin
> for Bugzilla.  GitHub sucks for code review, but there are external
> tools (including Gerrit) we could use.  GitLab, OTOH, has pretty good
> integrated code reviews.
>
> So, IMHO as soon as 0.34 is branched, we should start working on two
> things:
>
>1. Make it easier to add tests to valac (i.e., merge the Valadate stuff
>   from Chris Daley's repo).
>2. Write tests.  LOTS of tests.  Luckily, this doesn't require a great
>   deal of knowledge, so if you're looking for a way to start
>   contributing this could be an excellent choice.
>
> At the same time, we need to start talking about infrastructure.  I
> love the fact that Vala is part of GNOME, but we need to figure out how
> to get CI up and integrated with our issue tracker.  GNOME Continuous
> is great, but it's just not enough.  If this means moving to GitLab,
> GitHub, BitBucket, etc., or installing GitLab or Phabricator, then so
> be it.  IMHO this is more important than having Vala's issue tracker at
> the same place as GNOME's.
>
>
> -Evan
>
>
>
> On Thu, 2016-09-08 at 19:34 +0200, Timm Bäder wrote:
> > 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 

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

Re: [Vala] The future of Vala

[Baptiste Gelez]

Le 2016-09-10 23:58, Evan Nemerson a écrit :

On Sat, 2016-09-10 at 21:22 +, Ben Iofel wrote:

Sounds awesome. Even if we don't move to github, we should still
allow
people to submit pull requests on the mirror
(https://github.com/gnome/vala)


I completely disagree.  There should be one place to somehow request a
change in the code.  The only way we should accept pull requests
through a GitHub *mirror* is if they are transparently mirrored to the
canonical location, which is extremely non-trivial.

Obviously, without automatic mirroring you're forcing the developers to
monitor multiple channels, which sucks, but there are also other
consequences.  If the PRs aren't mirrored automatically they won't
properly interact with CI, which means they won't be properly tested.

You would also have to mirror all comments in both directions;
commenting on GitHub would have to result in a comment on the canonical
location so developers see them, and if a developer comments on the
canonical location it would have to be mirrored back to GitHub so the
contributor sees it.  You might be able to get a bot account going for
this, but then it's a poor experience for anything involving more than
one person on each site.

Even if you do mirror comments in both directions, you still couldn't
handle things GitHub doesn't support (like real code review).

Finally, I'm not sure it's fair to GNOME to accept PRs through GitHub.
It would set a precedent for other projects which isn't fair for them,
and likely end up making everyone more frustrated.

As for moving to GitHub instead of just accepting PRs through the
mirror, I really don't think that is the right answer here, and I say
that as someone who does a decent amount of open source work on GitHub
these days (see ).  Off the top of my head,
the pros are:

 * Most developers already have a GitHub account and are already
   comfortable with it.
 * Travis CI only works with GitHub.

Travis CI support doesn't really matter; there are lots of CI services
which do work with non-GitHub projects.

The cons, OTOH:

 * The issue tracker is absolutely terrible.  It's easy to use, but
   very limited.
 * Code review support is a joke; it's a stretch to even say it exists.
   It's really just an issue is opened, and you can add comments.
 * It's proprietary. Given the choice, I'd rather use open source
   software unless the proprietary stuff is *significantly* better.
 * There is no way to fix bugs or add features, and relying on GitHub
   doesn't work.  I've reported issues to them before and it has never
   done any good.

I could make that list a lot longer with a bunch of paper-cut type
stuff, but the final bullet point covers a lot.  Besides, the first two
issues negate a lot of the reason I think we should consider some
infrastructure changes.

Frankly, if the choice is between moving to GitHub and sticking to the
current setup I'd prefer the latter.  IMHO the tighter integration with
GNOME is more valuable than not making people sign up for another
account to contribute.


-Evan



I think Gitlab is a good solution (or at least a better solution than 
Github) :


- It's free/open-source software
- When you are comfortable with Github, Gitlab is easy to use
- You have got a good CI, with Gitlab CI
- Code review and issue tracker seems to be similar to Github's ones, 
but because it's open-source we could improve it, or send a request for 
it (Gitlab devs seems to be quite reactives to the feature requests). 
There is also a Bugzilla integration.

- We could also fix bugs if needed.
- You can log in with Github, if you don't want to create an account for 
a small contribution.


And if we don't want to depend of gitlab.com, we can host our own 
instance, perhaps on GNOME servers, if they want.


Baptiste
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] The future of Vala

[Al Thomas]

- Original Message -
> From: Evan Nemerson <e...@coeus-group.com>
> Sent: Saturday, 10 September 2016, 21:44
> Subject: Re: [Vala] The future of Vala

> Chris Daley has been working on moving a version of Valadate into the
> Vala tree (see <https://github.com/chebizarro/vala>) so tests are
> easier to write.  I'd like to get some feedback from people on his
> work, and if it would encourage people to write more tests we should
> merge it after 0.34 is branched.


Instead of 'make check' the Valadate version also allows you to:
cd tests
./valactests-0.34
This shows TAP output for the tests and produces a log in TAP
format called valactests-0.34.log This includes HTTP links to
bugzilla reports and can be fed into a CI system such as Jenkins.

Ultimately it would be nice to specify a subset of tests so test
first development could be made easier. Then run the full regression
suite once the feature is passing the initial tests.

I hope people like it,

Al
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] The future of Vala

[Evan Nemerson]

On Sat, 2016-09-10 at 21:22 +, Ben Iofel wrote:
> Sounds awesome. Even if we don't move to github, we should still
> allow
> people to submit pull requests on the mirror
> (https://github.com/gnome/vala)

I completely disagree.  There should be one place to somehow request a
change in the code.  The only way we should accept pull requests
through a GitHub *mirror* is if they are transparently mirrored to the
canonical location, which is extremely non-trivial.

Obviously, without automatic mirroring you're forcing the developers to
monitor multiple channels, which sucks, but there are also other
consequences.  If the PRs aren't mirrored automatically they won't
properly interact with CI, which means they won't be properly tested.

You would also have to mirror all comments in both directions;
commenting on GitHub would have to result in a comment on the canonical
location so developers see them, and if a developer comments on the
canonical location it would have to be mirrored back to GitHub so the
contributor sees it.  You might be able to get a bot account going for
this, but then it's a poor experience for anything involving more than
one person on each site.

Even if you do mirror comments in both directions, you still couldn't
handle things GitHub doesn't support (like real code review).

Finally, I'm not sure it's fair to GNOME to accept PRs through GitHub.
It would set a precedent for other projects which isn't fair for them,
and likely end up making everyone more frustrated.

As for moving to GitHub instead of just accepting PRs through the
mirror, I really don't think that is the right answer here, and I say
that as someone who does a decent amount of open source work on GitHub
these days (see ).  Off the top of my head,
the pros are:

 * Most developers already have a GitHub account and are already
   comfortable with it.
 * Travis CI only works with GitHub.

Travis CI support doesn't really matter; there are lots of CI services
which do work with non-GitHub projects.

The cons, OTOH:

 * The issue tracker is absolutely terrible.  It's easy to use, but
   very limited.
 * Code review support is a joke; it's a stretch to even say it exists.
   It's really just an issue is opened, and you can add comments.
 * It's proprietary. Given the choice, I'd rather use open source
   software unless the proprietary stuff is *significantly* better.
 * There is no way to fix bugs or add features, and relying on GitHub
   doesn't work.  I've reported issues to them before and it has never
   done any good.

I could make that list a lot longer with a bunch of paper-cut type
stuff, but the final bullet point covers a lot.  Besides, the first two
issues negate a lot of the reason I think we should consider some
infrastructure changes.

Frankly, if the choice is between moving to GitHub and sticking to the
current setup I'd prefer the latter.  IMHO the tighter integration with
GNOME is more valuable than not making people sign up for another
account to contribute.


-Evan


> 
> On Sat, Sep 10, 2016 at 4:44 PM 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.  However, we obviously also need
> > to
> > keep the compiler's code quality as high as possible.  There are a
> > lot
> > of unreviewed patches rotting away on Bugzilla right now, and
> > that's a
> > tragic waste of effort.
> > 
> > The answer, at least from my perspective, is to embrace automated
> > testing.  We need to significantly beef up the tests shipped with
> > the
> > compiler (the ones `make test` runs) so we can check make sure
> > patches
> > don't break anything.  This, in turn, would allow people a bit less
> > comfortable with the valac internals (such as myself) to review a
> > lot
> > more patches, and hopefully get development back up to a much
> > higher
> > rate.
> > 
> > Chris Daley has been working on moving a version of Valadate into
> > the
> > Vala tree (see ) so tests are
> > easier to write.  I'd like to get some feedback from people on his
> > work, and if it would encourage people to write more tests we
> > should
> > merge it after 0.34 is branched.
> > 
> > I'd also like to provide a robust way to have assorted projects
> > written
> > in Vala tested, which would be especially important for changes to
> > bindings.  We already have this to some extent (see
> > ), but there is no integration with
> > Bugzilla

Re: [Vala] The future of Vala

[Evan Nemerson]

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.  However, we obviously also need to
keep the compiler's code quality as high as possible.  There are a lot
of unreviewed patches rotting away on Bugzilla right now, and that's a
tragic waste of effort.

The answer, at least from my perspective, is to embrace automated
testing.  We need to significantly beef up the tests shipped with the
compiler (the ones `make test` runs) so we can check make sure patches
don't break anything.  This, in turn, would allow people a bit less
comfortable with the valac internals (such as myself) to review a lot
more patches, and hopefully get development back up to a much higher
rate.

Chris Daley has been working on moving a version of Valadate into the
Vala tree (see ) so tests are
easier to write.  I'd like to get some feedback from people on his
work, and if it would encourage people to write more tests we should
merge it after 0.34 is branched.

I'd also like to provide a robust way to have assorted projects written
in Vala tested, which would be especially important for changes to
bindings.  We already have this to some extent (see
), but there is no integration with Bugzilla
and it's not very well maintained (many projects are broken due to non-
Vala issues), and AFAIK the configuration isn't public so there is no
way for people to help.

There are a lot of great free CI services we can take advantage of to
improve this, including (off the top of my head):

 * Travis CI
 * AppVeyor
 * GitLab
 * Snap CI
 * Drone.io
 * Semaphore

We don't have to choose one; we can use multiple services (especially
if AppVeyor is one of them).

One major barrier here is Bugzilla.  I'm not really concerned with
requiring people to sign up for an account, and I really like the
workflow (especially with git-bz), but CI integration is a problem and
I'm not sure how to resolve it.

The obvious solution would be moving development to GitHub, but I'm
certainly uneasy about depending on a proprietary platform, and I'd
sure others would be as well.

Perhaps a better option would be moving to GitLab, or installing a
GitLab instance somewhere (possibly on the GNOME infrastructure?).
AFAIK Travis only supports GitHub, but Travis isn't our only option.
If it were up to me, I would probably move to GitLab.com.

Once we have good automated testing support, a good code review tool
would be extremely helpful.  If we stick with Bugzilla, I know it's
possible to integrate Gerrit, though AFAIK it would require a plugin
for Bugzilla.  GitHub sucks for code review, but there are external
tools (including Gerrit) we could use.  GitLab, OTOH, has pretty good
integrated code reviews.

So, IMHO as soon as 0.34 is branched, we should start working on two
things:

   1. Make it easier to add tests to valac (i.e., merge the Valadate stuff
  from Chris Daley's repo).
   2. Write tests.  LOTS of tests.  Luckily, this doesn't require a great
  deal of knowledge, so if you're looking for a way to start
  contributing this could be an excellent choice.

At the same time, we need to start talking about infrastructure.  I
love the fact that Vala is part of GNOME, but we need to figure out how
to get CI up and integrated with our issue tracker.  GNOME Continuous
is great, but it's just not enough.  If this means moving to GitLab,
GitHub, BitBucket, etc., or installing GitLab or Phabricator, then so
be it.  IMHO this is more important than having Vala's issue tracker at
the same place as GNOME's.


-Evan



On Thu, 2016-09-08 at 19:34 +0200, Timm Bäder wrote:
> 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 

Re: [Vala] The future of Vala

[Flavio Danesse]

I 'm spending all my applications python Vala , I would like to know the
current state of Vala . Maybe I can contribute in some way to its
continuity.

2016-09-09 18:50 GMT-03:00 rastersoft :

> Hi:
>
> I was hoping to see at least one answer to this, but now I'm really
> scared. I really love Vala, so the perspective of missing it is really
> horrible :(
>
>
> El 08/09/16 a las 19:34, Timm Bäder escribió:
> > 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
> >
>
> --
> Nos leemos
>  RASTER(Linux user #228804)
> ras...@rastersoft.com  http://www.rastersoft.com
>
> ___
> 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

Re: [Vala] The future of Vala

[Adam Tauno Williams]

On Fri, 2016-09-09 at 23:50 +0200, rastersoft wrote:
> I was hoping to see at least one answer to this, but now I'm really
> scared. I really love Vala, so the perspective of missing it is 
> really horrible :(

Ditto.  I've been poking at Vala - it seems like a really great idea,
and it worked well for what I tried so far  but I am extremely
hesitant to invest in another piece of abandonware.

Slouching sadly back to Python...

> > 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).

-- 
Adam Tauno Williams  GPG D95ED383
OpenGroupware Developer 


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

Re: [Vala] The future of Vala

[Al Thomas]

- Original Message -

> From: rastersoft <ras...@rastersoft.com>
> Sent: Friday, 9 September 2016, 22:50
> Subject: Re: [Vala] The future of Vala

> I was hoping to see at least one answer to this, but now I'm really
> scared. I really love Vala, so the perspective of missing it is really
> horrible :(


The email was only sent yesterday and in my view requires a considered response.
So please hold back from the fear, uncertainty and doubt (FUD).

My own view is Vala will trundle along as it has done for a while now. The 
question
is really whether development will pick up pace. I was going to respond with my 
own
view. That is based on a paraphrase of an old slogan "it's not what your 
community
can do for you, but what you can do for your community" and my own TODO list 
for Vala.
There is a stable release for Vala about to be released in the coming weeks as 
the
main releases coincide with GNOME release. So for my own part I wanted to focus 
on
getting a few patches in before then. Then I was going to put forward my own 
ideas,
but I am not a Vala developer.


Al
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] The future of Vala

[rastersoft]

Hi:

I was hoping to see at least one answer to this, but now I'm really
scared. I really love Vala, so the possibility of missing it is really
horrible :(


El 08/09/16 a las 19:34, Timm Bäder escribió:
> 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
>

-- 
Nos leemos
 RASTER(Linux user #228804)
ras...@rastersoft.com  http://www.rastersoft.com

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

Re: [Vala] The future of Vala

[rastersoft]

Hi:

I was hoping to see at least one answer to this, but now I'm really
scared. I really love Vala, so the perspective of missing it is really
horrible :(


El 08/09/16 a las 19:34, Timm Bäder escribió:
> 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
>

-- 
Nos leemos
 RASTER(Linux user #228804)
ras...@rastersoft.com  http://www.rastersoft.com

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