[haiku] Re: How to improve Haiku
- From: pulkomandy <pulkomandy@xxxxxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Sun, 27 Apr 2014 19:42:49 +0200
On Sun, Apr 27, 2014 at 06:59:47PM +0200, Charlie Clark wrote:
> Am .04.2014, 17:51 Uhr, schrieb pulkomandy <pulkomandy@xxxxxxxxx>:
>
> >I'll add that Gerrit also supports checking that the patch doesn't break
> >the build, and could easily be combined with an automated coding style
> >checker.
>
> That sounds very good especially in the absence of extensive test coverage.
>
> What do you do for static code analysis / code style check? Do you
> have a pre-commit lint hook?
This all happens post-commit. You push changes to Gerrit (instead of
directly to trunk), and the bot picks them up there. I think we can have
bot run whatever checks we want: style, build test, unit tests (if we
have some), code anamysis, whatever. The result is reported on Gerrit.
You can see an example of Gerrit running in the OpenOCD project:
http://openocd.zylin.com/
They use Jenkins to submit build results there. Buildbot, which we use,
seems to have some Gerrit integration as well:
http://docs.buildbot.net/0.8.3/GerritStatusPush.html
The checks are made on Gerrit, which is better than just rejecting the
push upfront. This way, other people can see how your patch failed to
build, and maybe take over it and try to fix it. Or you may get some
hints on the issues from people reviewing it anyway. Doing these things
at push time means the rejected changes will rot on the computer where
the patch was initially written, and not get a chance of getting public.
The fork + pull request model in github is somewhat similar, with a risk
of changes getting forgotten in some random fork of the project. This is
one issue our current Trac-based workflow doesn't have (but it has many
others).
I started a list of features, feel free to (fork and) complete it:
https://gist.github.com/pulkomandy/11351327
--
Adrien/PulkoMandy
Other related posts:
