Introducing: Haiku Format Bot 0.1

Development OS
1

Note: this is a cross-post with the haiku-development mailing list.

As announced in a previous email, I am working on a tool that integrates haiku-format, the tool maintained by @owenca, with Gerrit, in order to automate a lot of the manual style checking that is going on by contributors reviewing patches. I am now going to share the first pre-release, version 0.1. The main accomplishment in this release is that the logic for fetching a Gerrit change, running the diffs through haiku-format and then posting the outcome to Gerrit is implemented.

The current state of play can be found in the haiku-format-bot Github repository.

This is the first step towards having a fully automated style checker, but there is much to do. For the bot itself, I designed the following roadmap:

  • Version 0.2 (exp. February): Add a command to the repository to repeatedly self-select applicable changes and run the formatting check over them.
  • Version 1.0 (exp. April): Run haiku-format-bot as daemon on the Haiku Infrastructure and provide value to the project.

Besides the development on the bot itself, there is also going to be work on haiku-format to get it up to speed. In particular, I identified the class member formatting improvement as a must-have, as well as reviewing what we can do with the builder syntax used in layout builders (though that’s more of a nice to have in my current opinion).

I also suspect that some of the test runs will show reformats that need more discussion. For example, in the most recent run adds spaces after C-style casts. I suspect we will be finding more examples that need discussion.

Beyond the work on the code itself, I will do the following over the coming few weeks:

  1. I will create a service account on Gerrit to run the bot, so that it no longer runs under my name and is more recognizable.

  2. Create a label on Gerrit, that shows the evaluation of the style adherence if the bot is run. My suggestion is that for now it votes a 0 if there are changes, and +1 if no reformatting suggestions are made. I think introducing negative votes is a separate discussion, and we should have that after we have more experience with the bot and its output.

  3. Organize discussions/votes on potential changes to the Coding Guidelines and/or the configuration of haiku-format based on new cases we are finding during the trial runs.

  4. Continue trial runs over the coming weeks. Initially this will be individually selected changesets, but if all goes well, the bot will start running over more recently updated changes semi-automatically.

I will keep updating everyone on the progress, but feel invited to review the code and to post any ideas/worries/notes during this process.

12 Likes
2

Ahoy,

Does this event relate to this development ?

https://dev.haiku-os.org/ticket/18749

Cheers,

3

No. Gerrit has been restarted and is working again.

4

Thanks Niels; it will be very useful to have this automatic linting working.

5

I think the -1 vote would still be useful, if only to know that the bot has run.

Here is the documentation for custom labels:

https://gerrit-review.googlesource.com/Documentation/config-labels.html#label_custom

We can make them not required, so that a +1 vote from the bot is not needed to merge, and a -1 vote will not be blocking the change. But we can quickly look and know that the bot has scanned the change and has something to say. I think the bot itself can use this to easily scan the changes and know if it has already scanned a changeset or not?

The existing build checker bot from Madmax already does this (+1/-1 votes) and it seems to work fine for this one. -1 votes from bots are more socially accepted than -1 votes from developers, because they are more impartial.

6

I agree, on doing the -1, for the pragmatic reason that a 0 vote does not register as a vote and therefore it would make it more difficult to filter out the changes that already have been processed.