On Wed, 23 Sep 2020 at 14:33, David Edelsohn <dje....@gmail.com> wrote: > > On Wed, Sep 23, 2020 at 8:26 AM Christophe Lyon via Gcc <gcc@gcc.gnu.org> > wrote: > > > > On Wed, 23 Sep 2020 at 12:26, Richard Earnshaw > > <richard.earns...@foss.arm.com> wrote: > > > > > > On 23/09/2020 11:20, Jakub Jelinek via Gcc wrote: > > > > On Wed, Sep 23, 2020 at 10:22:52AM +0100, Richard Sandiford wrote: > > > >> So that would give: > > > >> > > > >> Results for 8.4.1 20200918 [r8-10517] on arm-none-linux-gnueabihf > > > >> > > > >> and hopefully free up some space at the end for the kind of thing > > > >> you mention. > > > > > > > > Even that 8.4.1 20200918 is redundant, r8-10517 uniquely and shortly > > > > identifies both the branch and commit. > > > > So just > > > > Results for r8-10517 on ... > > > > and in ... also include something that uniquely identifies the > > > > configuration. > > > > > > > > Jakub > > > > > > > > > > I was thinking similarly, but then realised anyone using snapshots > > > rather than git might not have that information. > > > > > > If that's not the case, however, then simplifying this would be a great > > > idea. > > > > > > On the other hand, I use subject filters in my mail to steer results to > > > a separate folder, so I do need some invariant key in the subject line > > > that is sufficient to match without (too many) false positives. > > > > > > > I always assumed there was a required format for the title/email > > contents, is that documented somewhere? > > There must be a smart filter to avoid spam, doesn't it require some > > "keywords" in the title for instance? > > > > Same question for the gcc-regression list: is there a mandatory format? > > The format is generated by contrib/test_summary.
That's true for gcc-testresults, and I was wondering what would happen if I modify test_summary? Does some mail-filter need fixing too? Regarding gcc-regression, I think only Intel guys send messages there (https://gcc.gnu.org/pipermail/gcc-regression/) and they use different formats, hence I'm curious about the constraints. > > - David
