Re: ELPA tests in EMBA?

[Stefan Monnier]

Ted Zlatanov [2021-01-20 09:56:05] wrote:
> On Tue, 19 Jan 2021 09:32:55 -0500 Stefan Monnier <monnier@iro.umontreal.ca> 
> wrote: 
>>> do you think it would be useful to test ELPA in the EMBA pipelines?
>>> I was wondering...
>
> SM> That's a good question.  I don't have any experience with running tests
> SM> in the various GNU ELPA packages, so I don't have a clear feeling for
> SM> how well this would work.
>
> Well, I hope we can help in some small way :)
>
>>> The ELPA tests can be completely different from the way we structured
>>> the Emacs tests.
>
> SM> One of the issues to deal with is that every GNU ELPA package has
> SM> (potentially) its own maintainer, so the reports for the "overall"
> SM> results may not be terribly useful to anyone, and instead each package's
> SM> report should likely be sent to its corresponding maintainer.
>
> SM> For the commit-diffs, I do that by forwarding the "elpa.git" commit
> SM> diffs email to elpa.gnu.org where I have a procmail script that figures
> SM> out which package is affected and then forwards the email accordingly.
> SM> That's fairly easy to do since the email's headers include information
> SM> about the affected branch.  We'd need similarly clear labeling in the
> SM> EMBA report emails.
>
> I think we can do that.
>
> SM> BTW, what I do know would be useful would be something that sends
> SM> a report about the byte-compiler's warnings (but only if we send it to
> SM> the maintainer: I already see the warnings on my side, I just find it
> SM> tedious to forward them to the maintainers).
>
> Understood. I think we can hack that as well. On EMBA we have a "base"
> Emacs image ready to do all this, with some safety inside a container.
>
> Do you want to put together your requirements in an e-mail to
> emacs-build-automation so we can work off that?

I don't really have any requirements: the above are more comments about
what I would find particularly useful, but I think anything is likely
going to be better than what we have now ;-)


        Stefan [ who's not on the `emacs-build-automation` mailing list.  ]