Re: Update of ELPA package guess-language

[Titus von der Malsburg <malsburg@posteo.de>]

On 2021-08-26 Thu 08:31, "Bozhidar Batsov" <bozhidar@batsov.dev> wrote:
>> But maybe adding :auto-sync t is needed for GNU ELPA.
>
> Seems like a prudent idea to me. I was surprised to learn that GNU
> ELPA and NonGNU ELPA behave differently in this regard. Perhaps
> there's some concern that changes that are not properly copyrighted
> might make their way into GNU ELPA?

Yes, and in my specific case the copyright situation is indeed unclear, which means that it would have been a mistake to automatically fetch the changes.

  Titus

>
> On Wed, Aug 25, 2021, at 2:51 PM, Tassilo Horn wrote:
>> Philip Kaludercic <philipk@posteo.net> writes:
>> 
>> >> A while ago I contributed the package guess-language to ELPA [1].  In
>> >> the meantime, I’ve added some improvements in my own git repository
>> >> but it’s not entirely clear to me how I can update the ELPA version.
>> >> From reading the ELPA README [2], it seems that I have to request an
>> >> update on this list every time there is (significant-enough) change
>> >> in my repo (since I wasn’t given push permissions).  Is that really
>> >> true?  I’m asking because I rarely see such requests here and because
>> >> it’s not a terribly efficient workflow.  Is there no way that ELPA
>> >> can automatically pull changes from the original repository?
>> >
>> > It should be possible, some package specifications (see elpa-packages)
>> > are given the :auto-sync attribute, but I am not sure what the
>> > conditions are for a package to be granted this status.
>> 
>> I can't find docs for :auto-sync.  Is that still in use, i.e., is there
>> any behavior associated with it?  At least Stefan said in [1] that
>> auto-sync is effective for all packages in NonGNU ELPA.  And indeed, I
>> can testify that changing stuff in my upstream repo and increasing the
>> Version will trigger a new NonGNU ELPA release.
>> 
>> But maybe adding :auto-sync t is needed for GNU ELPA.
>> 
>> Bye,
>> Tassilo
>> 
>> [1] https://lists.gnu.org/archive/html/emacs-devel/2021-08/msg00533.html
>> 
>>