gerrit-buildbot master builds

[Bjoern Michaelsen]

Hi,

so, I finally downloaded the the gerrit-buildbot plugin source and had a look
at the code. I wonder if we could make it to do the following:

- allow scheduling building a generic sha1, not just changes for review
- somehow store the results of such builds

That would allow us to get rid of annoying 'the builders have to serve both
tinderbox.libreoffice.org and the gerrit-buildbot at the same time' and make
the buildbot schedule queue in control alone.

A suggested solution would be:

- make eat 'buildbot schedule -p core nochange:56a52889e65a17e324fc10cf341690385f5a9dd9'
- make buildbot store the result reported by a 'buildbot put' (last 1000
  results or so would be fine)
- and make it parseable in 'buildbot show'

This would allow us to:
- make the tinderbox to just run against the gerrit plugin without having to notify
  tinderbox.libreoffice.org or switching between both
- e.g. have a cronjob (outside of both the buildbot plugin and the tinbuild2
  script) that, if nothing is scheduled, schedules the latest master without
  having this logic in the buildbot or in the tinderbox
- e.g. have the same cronjob forward the results to tinderbox.libreoffice.org
  as long as we still need that

In the long run this would enable:
- if a patch verification breaks, check if the base master was already broken
  (if so, those responsible should be sacked)
- maybe even bisect down master, if this happens.

This would:
- give a better migration path for existing tinderboxes
- make us have one central dispatch queue, instead of two things running
  uncoordinated side-by-side
- eases the 'master-is-broken-cant-review'-pains and motivates to use gerrit
  more at the same time (a bisect that ends on a master commit should result in
  peer pressure to use more gerrit)

Opinions?

Best,

Bjoern