I've rebased my changes onto a fork of Guile's main branch on Github: https://github.com/dadinn/guile/tree/wip-hygienic-expect Added back the original attributions and comments. I've also tried to follow the branch-naming conventions. 😉 Also, I've added a module ice-9/expect-tests for some comprehensive tests. Wasn't sure where to place it, and how to integrate into the existing test-suite. Not sure how to send a PR by email, but I suppose it should be easy to pull, by adding my fork as an additional remote. Best regards, Daniel Dinnyes On Mon, 29 May 2023 at 22:33, Maxime Devos wrote: > >p 29-05-2023 om 03:40 schreef Daniel Dinnyes: > > Thanks for the reply. > > > > On Sun, 28 May 2023 at 14:39, Maxime Devos > > wrote: > > > > I think this would gather more replies if: > > > > 1. It is sent as a patch that can be applied to the Guile source > > tree. > > > > (You wrote: > > > > > If the community likes this implementation, I would be happy to > > > apply/rebase my changes onto the official repo, and then we can > go > > > from there! > > > > but to determine whether I'm happy with it, it would be convenient if > > this were a proper patch.) > > (I'm not actually reviewing Guile stuff at the moment, but I find it > > likely that some others might hold the same view.) > > > > > > Regarding patches, I think I've read somewhere that GNU wants > > contributions in some different format, > > than just URLs to pull-able GIT repos. Could you share with me some > > guide how to do such patches, > > or what format they are needed? > > Format: the result of 'git send-email', or 'git format-patch + attach > the patch as an attachment'. I've heard that the guide at > for 'git send-email' is good. > > Still, setting up a fork + sending a PR (by e-mail), while not the most > preferred format, would still be pretty good (‘git diff’ can then be > used!). > > > I am assuming this is > the > > repo of current guile tree, onto which to apply my changes. > > Yes. > > > Onto which branch? > > The branch named 'main'. > > > Would it possible to fork the repo on savannah, and then raise a PR from > > there instead of patches? > > Savannah doesn't have a notion of 'forks' AFAIK. (Emphasis on the ‘I > don't know’ in ‘AFAIK’, maybe it actually does have them in some form.) > > However, you can do a PR ‘manually’ by setting up a fork of the repo at > some random hosting site of your choice, pushing some commits there, and > sending a (free-form) e-mail to guile-devel@gnu.org with a message > containing information on where to find the repository and which > branch/commit. > > (You don't need PR / fork buttons to do PRs and forks!) > > > Also, I've tried to create account on savannah, but it keeps getting > > deleted. > > What would you recommend I do to ensure my account doesn't get removed? > > I don't have clue; I only fetch from savannah, I don't have an account > there. > > > [...] > > I am not sure I would agree with your assessment about /illegality/, and > > the /derivative work/ categorization. > > Even though these macros happen to expand to something similar as the > > original ice-9 implementation, > > the code itself is quite significantly different! If this is to be used > > in ice-9, it would have to completely > > replace the original expect.scm file, as nothing was copy/pasted from > > there. The fact that parameter binding > > names are the same is necessary for backwards compatibility, so those > > wouldn't count even under the US laws > > . > > I assumed it is a derivative work because you presented it as a ‘rewrite > of [the original]’. Maybe it's possible to rewrite something a lot > until its no longer a derivative work (I don't know if that's possible), > but by default I'd assume that rewrites are derivative works. > > I didn't use ‘same procedure names’ as a reason (as you wrote, those > aren't a problem). > > > On second thought, I am wrong! The expect-select helper function looks > > like a direct copy-paste job... little naughty me! > > TBC, I ascribe no guilt. The thing is that I've noticed in the past > that people often use the GPL without knowing what that entails > precisely, which can have unintended consequences, like e.g. > unintentionally licensing something as GPLv1+ instead of GPLv3+ (or > GPLv3+ instead of GPLv3, but that mistake is actually pretty convenient > for distributions :P). > > (Also, Guile relies on the (L)GPL as a form of protection against some > forms of malice, so I think it's important that we also follow the > (L)GPL terms itself.) > > > Nevertheless, I would be happy to add the necessary notices if that is > > required. > > Also, IIRC there would be another copyright assignment administrative > work > > somewhere down the line? > > The copyright assignment used to be required, but nowadays its optional. > Still, it does appear to be preferred. You would get an e-mail by a > Guile maintainer with more info, it's not something you initiate yourself. > > The page https://www.fsf.org/licensing/contributor-faq sort-of implies > the opposite, but IIRC there is another page somewhere or gnu.org that > doesn't; I don't know what's up with that. (Either way, I'd think that > things will work out in the end.) > > Best regards, > Maxime Devos >