[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-smalltalk] adding smalltalk-mode to ELPA?

From: bill-auger
Subject: Re: [Help-smalltalk] adding smalltalk-mode to ELPA?
Date: Tue, 26 Mar 2019 23:04:21 -0400

On Wed, 27 Mar 2019 09:05:20 +0800 Derek wrote:
> I can maintain smalltalk-mode on ELPA and do the 2
> way sync required.

i am still completely baffled about this fixation in having the
upstream's approval, cooperation, or involvement in the packaging
process - you have everything you could possibly need to do this on
your own - no explicit permission nor assistance is required

it is irrelevant where, or in what form the upstream publishes the code
that you are interested in - as the downstream packager, you simply
watch the upstream for changes, then pull in the changes and rebuild
the package at your leisure - how that gets done precisely, is a
peculiar combination of the form in which the upstream publishes its
code, and the quirks of the requirements/protocols of the target
packaging format and repo admins - it is entirely the task of the
packager to make that happen, by whatever means necessary - there is no
need for the upstream to be involved in that process nor even be aware
that it happened

what has me particularly perplexed, is the: "two-way sync required" -
developers and packagers are in an "upstream/downstream" relationship -
that very terminology indicates a one-way flow of information -
anything flowing back upstream, does so in the form of patches - even if
those patches are in the form of a git commit and a webby "pull
request", that is not the philosophical equivalent of a two-way sync -
maybe this is just a confusion of words - i assume what you meant by
that, is that you would keep a mirror in sync; but to be clear, that is
a one-way, passive operation

it sounds like what you are asking, is for the upstream to maintain the
packaging repo for you; which would be very unconventional - you may as
well ask them to additionally maintain yet another packaging repo for
debian, another for fedora, another for arch, and so on; but debian,
fedora, and arch do not expect upstreams to do that - upstreams are not
expected to cater to the quirks of any specific package managers -
upstreams publish tarballs, period - the debian packager maintains the
debian packaging repo (in whatever way is appropriate for debian), the
arch packager maintains the arch packaging repo (in whatever way is
appropriate for arch), and as well, the ELPA packager should maintain
the ELPA packaging repo (in whatever way is appropriate for ELPA)

even if full automation is desired, `curl` or `git filter-branch` and 5
minutes per year are all that anyone would need to maintain a package
for this - i just do not understand the presumption that the upstream
should need to do anything at all to assist with that

reply via email to

[Prev in Thread] Current Thread [Next in Thread]