From: Stefan Monnier <monnier@iro.umontreal.ca>
To: "Basil L. Contovounesios" <contovob@tcd.ie>
Cc: emacs-devel@gnu.org, Oleh Krehel <oleh@oremacs.com>
Subject: Re: [elpa] main 8f4cb59: * elpa-packages (counsel, ivy, swiper): Auto-sync.
Date: Thu, 11 Mar 2021 10:48:26 -0500 [thread overview]
Message-ID: <jwvwnudn1l0.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87eegn18rr.fsf@tcd.ie> (Basil L. Contovounesios's message of "Wed, 10 Mar 2021 12:40:56 +0000")
>> - change the versions after merging rather than before (as mentioned
>> above). It's an easy low-tech solution, but it involves N times more
>> work if a single .git upstream version leads to N downstream releases.
> O(2N) is still O(N) though, so not much worse than the status quo.
;-)
>> - as discussed earlier, we could have each subpackage have the complete
>> upstream Git and only create the subpackages via `elpa-package`
>> filtering out the other files.
> That would be nice to have in general, but it doesn't solve the
> inefficiency when multiple packages are bundled from the same repo.
I don't understand the "when ..." qualification, since my suggestion is
only meaningful in that precise case. As for the inefficiency: as long
as the upstream is not enormous and that we don't have too many packages
following that model, it's bearable.
> Unless, of course, we either stop caring about the inefficiency (run out
> of hair to pull?) or significantly complicate the Git dance, e.g.:
> https://stackoverflow.com/q/600079/3084001
No subtree: I really mean the whole Git branch being duplicated
will-nilly for each subpackage.
>> - if there's really only one version number shared by all the
>> sub-packages, I'd tend to argue that maybe there should only be one
>> package ;-)
> I tend to agree ;). Not my call to make, though, and that ship is
> either getting smaller or sailing away.
>> - split the upstream repository.
> Not my call to make.
Of course it can also be a mix of the two and it can be done in bits and
pieces: every bit helps. So maybe we can start by lobbying the upstream
for one specific subpackage we identified as being a good candidate for
either a separate upstream repository or for having the subpackage be
merged with another.
>> a "don't look for commit in history" (after all, that's what the old
>> GNU ELPA script used to do: it used whichever commit was
>> HEAD when we discovered that the `Version:` "had changed" (meaning
>> the version in HEAD corresponds to not-yet-built file)).
>
> The bump-after-merge works better for me personally, as I don't have to
> worry about when to push which commits.
I know what you mean: that's exactly why the new code goes to the
trouble of checking the commit that modified the `Version:` line.
It's all too common for me to want to bump the version right before
installing experimental new code.
> I guess another alternative to :version-map would be Git tags?
> E.g. using an N.N.N-elpa scheme or something like that.
Fetching tags from upstream is problematic (because we have a single
elpa.git repository for all packages), but we could use tags manually
pushed to elpa.git, yes.
Stefan
next prev parent reply other threads:[~2021-03-11 15:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210225102521.11653.64611@vcs0.savannah.gnu.org>
[not found] ` <20210225102523.7CEF420B28@vcs0.savannah.gnu.org>
2021-02-25 14:33 ` [elpa] main 8f4cb59: * elpa-packages (counsel, ivy, swiper): Auto-sync Basil L. Contovounesios
2021-02-25 15:12 ` Stefan Monnier
2021-02-25 16:24 ` Basil L. Contovounesios
2021-02-25 16:40 ` Stefan Monnier
2021-03-09 22:17 ` Basil L. Contovounesios
2021-03-09 23:56 ` Stefan Monnier
2021-03-10 12:40 ` Basil L. Contovounesios
2021-03-11 15:48 ` Stefan Monnier [this message]
2021-03-11 17:12 ` Basil L. Contovounesios
2021-03-11 17:34 ` Stefan Monnier
2021-03-11 19:25 ` Basil L. Contovounesios
2021-03-11 22:47 ` Stefan Monnier
2021-03-11 22:59 ` Basil L. Contovounesios
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvwnudn1l0.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=contovob@tcd.ie \
--cc=emacs-devel@gnu.org \
--cc=oleh@oremacs.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.