+1 --
* EOF * 2016-09-10 22:44 GMT+02:00 Evan Nemerson <e...@coeus-group.com>: > 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 > > _______________________________________________ > 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
