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.maude...@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. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
