unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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.



  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).