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 <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. 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 <http://paldo.org:8010/>), 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 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 broke 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
Attachment:
signature.asc
Description: This is a digitally signed message part