[haiku] Re: How to improve Haiku
- From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Tue, 29 Apr 2014 09:58:15 +0200
On 2014-04-27 at 19:42:49 [+0200], pulkomandy <pulkomandy@xxxxxxxxx> wrote:
> 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
After having looked at the gist and reading about the pros and cons of the
approaches gerrit and github take at making it easy to integrate "external"
contributions, I'd very much like to second the notion of using gerrit.
As a first step, I'm going to provide a test installation on vmrepo when I
find the time. When that is available, we can all try out the process and
see if it indeed fits our needs.
In order to avoid the need for yet-another-password-storage, I'd like to
make use of gerrit's openID authentication. If anyone has (administrative)
experience with openID, please share your insights, as I have never used it
before.
cheers,
Oliver
Other related posts:
