From: Philip Kaludercic <philipk@posteo.net>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: Packages for old Emacs versions
Date: Wed, 16 Mar 2022 16:08:42 +0000 [thread overview]
Message-ID: <878rt95185.fsf@posteo.net> (raw)
In-Reply-To: <87wngvocy8.fsf@gnu.org> ("Ludovic Courtès"'s message of "Tue, 15 Mar 2022 09:08:15 +0100")
Ludovic Courtès <ludo@gnu.org> writes:
> Hi,
>
> Philip Kaludercic <philipk@posteo.net> skribis:
>
>> Thiago Jung Bauermann <bauermann@kolabnow.com> writes:
>>
>>>> My fear is that with further upstream development,
>>>> there might be conflicts between the packages I inherit from (emacs,
>>>> emacs-no-x, emacs-minimal) and the packages I have definined in [1].
>>>> An easy fix might be to not rely on the upstream package definitions,
>>>> but I am not certain if there are any down-sides I haven't considered.
>>>>
>>>> Of course, if the Guix project isn't interested in providing old
>>>> versions of packages, then I will continue look into maintaining my own
>>>> channel.
>>>
>>> I don’t have much experience with the Guix projects and its preferences
>>> and practices, so I can’t tell if it would be interested or not,
>>> unfortunately. I just wanted to mention that if not, another upstreaming
>>> option could be the Guix-Past channel:
>>>
>>> https://gitlab.inria.fr/guix-hpc/guix-past
>>
>> While interesting, this appears to be a closed project, so I am
>> uncertain how I could contribute my package definitions upstream.
>
> Contributions to Guix-Past are open to anyone. Unfortunately, creating
> an account on gitlab.inria.fr is pretty tedious (essentially you need to
> put me as your “mentor” when applying for an account), in addition to
> being annoying in the first place.
>
> I think we could consider moving it to a more convenient place, be it
> sr.ht, notabug.org, or even Savannah (in which case we’d use the same
> workflow as with the rest of Guix).
>
> Thoughts?
Personally I would prefer an anything that doesn't use the GitHub-esque
"Pull Request" mechanism, and I guess as long as it is all Free
Software, Savannah should do the job.
>> Would it be unconventional for me to try and set up my own repository?
>
> No, of course not. It’s better if we can team up IMO, but if
> maintaining your own repo works better for you, that’s okay.
I would certainly appreciate it, having run into a number of issues and
being frequently confused while writing the package definitions I had
linked above.
> Thanks,
> Ludo’.
--
Philip Kaludercic
next prev parent reply other threads:[~2022-03-16 16:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-06 15:40 Packages for old Emacs versions Philip Kaludercic
2022-03-08 1:20 ` Thiago Jung Bauermann
2022-03-13 20:53 ` Philip Kaludercic
2022-03-15 8:08 ` Ludovic Courtès
2022-03-16 16:08 ` Philip Kaludercic [this message]
2022-03-08 12:05 ` zimoun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878rt95185.fsf@posteo.net \
--to=philipk@posteo.net \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).