Re: [Libreoffice] breathing master

Hi Caolán,

On Mon, 23 May 2011 15:50:40 +0100
Caolán McNamara <caolanm@redhat.com> wrote:

> I think we have a three things here
> a) broken tinderboxes/build
> b) overly noisy list
> c) unreviewed patches
Right, sorry to have mixed those.

> The needs-X-reviews is a bit tedious alright. Maybe these can be
> bumped off into a release list or run through bugzilla or sommat
> instead.
I dont think a separate list would work. Some patches would still be
posted to the ML, some not, it would end up as a mess. Something
picking up patches and putting them on bugzie or gerrit could work
though (with the option for people to publish patches there personally).
 
> On this specific topic, the emails from the tinderboxes generally
> don't include the actual error where the build broke. That's the no 1
> problem IMO with the tinderbox mails, they don't give the actual
> error.
This should be an nonissue for most things with gbuild and tail_build.
Unfortunately binfilter currently messes that up quite often.

> I'd like to see build-break mails with the error actually
> inline in them as a first step.
> This may simply be a outcome of parallel builds ? As a quick-fix maybe
> having the buildbots auto restart with a single proc build would
> resolve that in that case.
Sounds good. Norberts proposal is also good, even if a little bit more
work.
Also, as of now, I might get a nagmail from the tinderbox simply
because I commited to a known broken build, making me feel less
responsible. I still want that mail to go to all commiters since the
last good build. But it would be great to explicitly point out the
commiters and commits to the _first_ build that broke, because they are
most likely guilty.

> Is it the case that list-submitted patches are the patches that are
> breaking the builds ?. Would be cool to auto commit patches to a
> branch and build it and mail results to submitter on failure, but
> would only make sense to go to that effort if the bottleneck is a lot
> of broken list-submitted patches.
True. I was thinking more along the line of having the "unreviewed"
branch serving primarily as a review queue. Doing a tinderbox builds
over them is just a bonus. Anyway: Having an opportunity to have any
bigger set of patches tinderboxed before they hit master would be a big
win.
An alternative is to do it the other way around: Create a branch
"tinderboxed" that regularly pulls from master up to the state that:
- windows has build and smoke/subsequenttested
- any one unix platform has build and smoke/subsequenttested
- is not known to be broken on any platform
It would provide a good point for rebases and starting branches.

> I agree that its definitely good policy that the w/e build "just
> work", for myself I tend to avoid making dramatic checkings at 5pm on
> a Friday. I'm not a massive fan of a collective sit down and patch
> review, sometimes I have an hour or 10 mins to do a review or two,
> and sometimes I don't. Setting aside a fixed-schedule block of time
> is problematic.
I dont think we should schedule a you-have-to-be-there-date. Maybe we
will just try to have a look around on Monday 15:00 UTC on IRC and
harvest for patches with whoever is there? No oligations etc. Just a
nice informal half an hour of hug-a-patch.

Best,

Bjoern

-- 
https://launchpad.net/~bjoern-michaelsen