From: Philip Kaludercic <philipk@posteo.net>
To: Adam Porter <adam@alphapapa.net>
Cc: emacs-devel@gnu.org, tonyzorman@mailbox.org
Subject: Re: package-vc support for :files keyword
Date: Tue, 19 Sep 2023 13:56:23 +0000 [thread overview]
Message-ID: <878r92b720.fsf@posteo.net> (raw)
In-Reply-To: <01436d9f-d8eb-9708-08cc-dbfd2848b3fc@alphapapa.net> (Adam Porter's message of "Tue, 19 Sep 2023 07:23:14 -0500")
Adam Porter <adam@alphapapa.net> writes:
> Hi Philip,
>
> On 9/19/23 03:37, Philip Kaludercic wrote:
>
>>> Please note out that while `taxy' and `taxy-magit-section' are both
>>> developed in "taxy.el.git", they are in separate branches, so there is
>>> no need to build the two packages from a single set of files by
>>> excluding some files and then the others.
>> Oops, I just wrote a quick script that compared URLs but did not
>> check
>> what :branch they are developed on.
>>
>>> I've chosen to keep these packages in the same repo because they are
>>> so closely related. I'd like to be able to keep this arrangement.
>> That is totally fine, would you mind sharing your setup, in case
>> someone
>> else is interested in this approach as well?
>
> I'm not sure what you're asking for, but I'll be glad to share. All I
> did was create an orphan branch in the same repository and add the
> "taxy-magit-section.el" and associated files there, as if it were a
> separate repo.
What I meant was if you just had multiple, separate checkouts of the
same repository or were using something more fancy like git worktrees.
>>> Having said that, while I wouldn't personally object to dropping
>>> support for building multiple packages from a single branch (since I
>>> don't do it myself), I wouldn't favor doing so, because existing
>>> packages do, and it would create more work for the authors to have to
>>> split them up.
>> That is the issue, and I certainly don't want to be the one to blame
>> for
>> breakage, be it for package developers let alone users.
>>
>>> Maybe it would be reasonable to make a new policy against building
>>> multiple packages from a single branch, while "grandfathering" in the
>>> existing packages that do so, if it would solve a problem for ELPA.
>> What do you mean by "grandfathering"?
>
> It's an expression; in this context, it would mean to allow the
> packages that already work this way to continue doing so, while
> requiring newly submitted packages to only build one package per
> branch (or repo, depending on the policy).
FWIW I have been bringing this up whenever a package like this was
proposed, but usually they refer to existing users on MELPA and then I
don't want to bother them any further.
next prev parent reply other threads:[~2023-09-19 13:56 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-10 10:53 package-vc support for :files keyword Daniel Fleischer
2023-06-10 13:23 ` Philip Kaludercic
2023-06-10 14:20 ` Daniel Fleischer
2023-06-11 8:55 ` Philip Kaludercic
2023-06-11 9:30 ` Daniel Fleischer
2023-06-11 10:24 ` Philip Kaludercic
2023-09-18 7:25 ` Tony Zorman
2023-09-18 9:10 ` Philip Kaludercic
2023-09-18 14:43 ` Tony Zorman
2023-09-18 15:52 ` Philip Kaludercic
2023-09-18 18:54 ` Adam Porter
2023-09-19 8:37 ` Philip Kaludercic
2023-09-19 12:23 ` Adam Porter
2023-09-19 13:56 ` Philip Kaludercic [this message]
2023-09-19 14:14 ` Adam Porter
2023-09-18 19:40 ` Tony Zorman
2023-09-19 8:47 ` Philip Kaludercic
2023-09-19 13:48 ` Adam Porter
2023-09-19 14:00 ` Philip Kaludercic
2023-09-19 14:17 ` Tony Zorman
2023-09-20 7:32 ` Philip Kaludercic
2023-09-21 13:28 ` Tony Zorman
2023-09-21 16:32 ` Philip Kaludercic
[not found] ` <87jzsgm82h.fsf@hyperspace>
2023-09-24 14:31 ` Philip Kaludercic
2023-09-25 13:32 ` Tony Zorman
2023-09-27 14:03 ` Philip Kaludercic
2023-10-04 6:44 ` Tony Zorman
2023-09-19 22:51 ` Jonas Bernoulli
2023-09-22 12:38 ` Stefan Kangas
2023-09-22 13:26 ` Philip Kaludercic
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://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878r92b720.fsf@posteo.net \
--to=philipk@posteo.net \
--cc=adam@alphapapa.net \
--cc=emacs-devel@gnu.org \
--cc=tonyzorman@mailbox.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/emacs.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).