Re: Guile 3 and wip-elisp/Emacs

[Christine Lemmer-Webber <cwebber@dustycloud.org>]

Robin Templeton <robin@terpri.org> writes:

> Christine Lemmer-Webber <cwebber@dustycloud.org> writes:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Hello!
>>>
>>> Christine Lemmer-Webber <cwebber@dustycloud.org> skribis:
>>>
>>>> I've pushed this as origin/wip-elisp-rebased.  I actually rebased it
>>>> again, making some naming adjustments for myself and a couple of
>>>> adjustments having talked to Robin.
>>>>
>>>> If nobody objects, I'd like to merge this into main.  Maintainers, if
>>>> you have any objections, speak now or forever hold these commits!
>>>
>>> I haven’t looked at the branch, but I think it’s great to see it live
>>> and it’s great if it can be merged!
>>
>> I just compiled the rebased version and will be playing with it little
>> bits over the next few days to make sure it's reasonably good.
>>
>>> Some things to pay attention to before merging to ‘main’, since it
>>> corresponds to the current 3.0 stable branch:
>>>
>>>   • Make sure no backward incompatibilities are introduced in
>>>     preexisting modules;
>>>
>>>   • Make sure the ABI of libguile-3.0.so and that of public modules
>>>     is unchanged, or is changed compatibly;
>>
>> There are, I think, two commits that could use review, but I am NOT the
>> right person to do this.
>>
>>   4e96211eb666751b8666beb918bf3108aa1c725b intern arbitrary constants
>>   433fc448ddb018767906f8808203c9668c68cd83 multiple obarrays
>
> I'll take a look at these...
>
>> [...] (and maybe the "guile-private-ref" and "allow
>> arbitrary constants in cps" commits look relevant too).
>
> and these, but concur that Andy is the best person to review them, and I
> agree that Andy should approve the merge overall in any case.
>
> Still reviewing the wip-elisp-rebased branch in my spare time; so far I
> haven't found any noteworthy problems, not that I was expecting to :)
>
> A minor point: IMHO the "(Best-ability ChangeLog annotation ...)" lines
> aren't the ideal way to credit you, in terms of commit message
> formatting. I'd prefer using git 'trailers' for in-commit credit, so
> that it's obvious to both humans and git that it's commit metadata. I'm
> not sure there's a conventional git trailer for this...something like
> 'ChangeLog-by:' would be probably be clear enough. But if you prefer the
> current formatting and it works with Guile's ChangeLog generator, I
> don't mind leaving it as-is (except perhaps "s/Best-ability //" after
> I've reviewed everything :)) WDYT?

I'm fine changing it.  The original reason for the "best ability" notes
was that I was more or less making up text to make it compatible with
the changelog style based off of reading your code.  Honestly the
attribution part isn't the most important to me but the "ChangeLog-by is
an interesting idea".  Most importantly, I want to get it in! :)

> Thanks,
> Robin