Enabling Buildbot 'responsible user' emails.

[Christian Mauderer]

On 06/02/2020 06:31, Amar Takhar 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.

I'm not strictly against sending these mails. They sound quite useful.
But there is an edge case that maybe should be discussed too:

What if we apply a patch for some driver or library that is just ported
to RTEMS but the person who wrote the patch didn't write it directly for
RTEMS? I know that we had such a case in the past in libbsd. I don't
remember the details but it was about the following:

Someone applied a FreeBSD patch directly to libbsd (which works well).
In that case git noted that the original author is in the "from" header
and send him an email that his patch has been applied. He was a bit
astonished to receive that mail.

Most likely it's a lot harder to construct a similar situation for the
RTEMS core repository. But I wouldn't entirely rule it out. Is there
some possibility to avoid such mails or do we just accept that in the
worst case someone unrelated receives mails?

Best regards

Christian

> 
> 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.
> 
> 
> Amar.


-- 
--------------------------------------------
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.