On Wed, Feb 5, 2020 at 10:31 PM Amar Takhar <a...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
