emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New "make benchmark" target


From: Stefan Kangas
Subject: Re: New "make benchmark" target
Date: Sun, 15 Dec 2024 00:57:40 +0000

Pip Cet <pipcet@protonmail.com> writes:

> Just to be clear, dropping the branch in GNU ELPA wouldn't mean that the
> package would no longer be available, just that it would build signed
> packages from the main Emacs repo?

Yes.

>> João has some scripts that he used for eglot, and I adapted them for
>> use-package.  Note that he also had some copyright assignment issues to
>> take care of, so it could probably be simplified.
>>
>> Please take a look here:
>> https://gist.github.com/joaotavora/2ed97f2ec85958986983d5cb78202770
>
> Thanks for the pointer!  I tried getting that to work, and finally
> succeeded in creating a (local) merged brach, but then I noticed that
> the commit messages will need editing to conform to the ChangeLog style.

I guess there's no clear drawback creating the ChangeLog entries for
each commit, but it's not required.  Only the final merge commit needs a
ChangeLog entry.

I guess that entry will look something like this:

    * lisp/emacs-lisp/elisp-benchmarks.el:
    * lisp/emacs-lisp/benchmarks/bubble.el:
    * lisp/emacs-lisp/benchmarks/pidigits.el: New files.

(Incidentally, this is the same ChangeLog entry we would use if we just
copied the files without preserving history.)

> We also need to decide on the directory structure; right now, I've
> created a lisp/emacs-lisp/benchmarks/ directory; I'd prefer
> lisp/benchmarks (which would make it easier to exclude the benchmark
> files from compilation), but I don't have a strong preference and others
> should make that decision.  (I haven't included the
> lisp/emacs-lisp/subdirs.el file, but if we decide to keep the benchmarks
> in lisp/emacs-lisp/benchmarks/, we'll need to gitignore that, too).

I don't have a strong opinion here, but maybe this stuff belongs under
test/ even?

> I'm not sure how to proceed here.  Since there aren't that many commits,
> I can offer to change the commit messages myself, but I fully understand
> if someone else (Andrea or another volunteer) wants to do it.

FWIW, I'd just go ahead without waiting for someone else.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]