Enabling Buildbot 'responsible user' emails.

Gedare Bloom gedare at rtems.org
Thu Feb 6 15:03:10 UTC 2020


On Wed, Feb 5, 2020 at 10:31 PM Amar Takhar <amar at rtems.org> wrote:
>
> On 2020-02-05 20:28 -0700, Gedare Bloom wrote:
> > I would like it to be a single email to indicate there is a new
> > breakage. Enough to indicate "hey go take a look at the full build
> > results! something is wrong here"
>
> That's what it does.  Breakage isn't always the same across builds.  Waiting
> until the end to send a 'summarised' email would take hours if not a day.  Soon
> as the first build is broken the email is sent out.
>
> If we had more hardware to build BSPs in a more parallel fashion this could be
> possible right now it's out of our means.
>
>
> > It should be opt-in to the full results.
>
> That is what submitting source for the repository is.  An opt-in to getting an
> email letting you know that your changes have broken something.
>
> It's not very often someone is going to break every BSP.  I'd rather do this and
> deal with if and when it's a problem.  The only feasible way that could happen
> is if someone doesn't test their build.
>
> The second way is for someone to submit code that requires a tool upgrade.  That
> can be avoided by notifying me that the tools need to be upgraded.
>
> Right now all this work is unfunded I do have a design and plan to have the
> tools automatically build continuously which would avoid the second problem
> entirely.
>
I agree with what you say. (And appreciate the unfunded work.)

I still have reservations about the possibility to generate 250 emails
all basically the same. Perhaps developers/committers should test
every commit. Sometimes though we have purposefully allowed one commit
to be broken followed by the next that fixes it. (Of course, this
makes bisecting harder, so maybe it is bad practice.) I think the one
exception that should allow this practice is when we import code from
elsewhere, and then fix it up after.  This is also the case that would
potentially cause some unwitting soul to receive this blast of emails.

So, if this "Responsible User" email policy goes into effect, we also
need some additional policies for developers to help prevent the
"RTEMS Horde of Broken Builds" (TM) emails especially from going
outside of the core developers who at least might expect the noise.

Essentially a statement like:
1. All committers will test each commit from other authors to ensure
they build on (Tier 1?) architectures before pushing.

We already have similar statements about submissions, but it is good
to cross-check committers. I'm not quite sure if we have codified any
of these processes. A quick search only yields:
https://docs.rtems.org/branches/master/eng/vc-authors.html#commands
https://devel.rtems.org/wiki/Developer/Contributing#Testing

>
> Amar.
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel


More information about the devel mailing list