emacs-devel
[Top][All Lists]
Advanced

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

Re: Adding packages to ELPA


From: Stephen Leake
Subject: Re: Adding packages to ELPA
Date: Sat, 20 Sep 2014 11:09:15 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (windows-nt)

Eli Zaretskii <address@hidden> writes:

>> From: Stefan Monnier <address@hidden>
>> Cc: address@hidden
>> Date: Fri, 19 Sep 2014 12:34:54 -0400
>> 
>> >> - GNU ELPA packages can be released on their own schedule.
>> > Same is true if they are in the Emacs repository.
>> 
>> Not really.  There are always interferences one way or the other between
>> Emacs's release cycle and the packages's own release cycles.
>
> No, I mean that a package that is part of Emacs can be used to create
> a separate tarball disregarding the rest of Emacs.  After all, once
> you checkout the repo, they are just file in a certain directory.

How would the typical Emacs/ELPA user use that "separate tarball"?

Currently, to release a new version of Ada mode, I just update the elpa
repository, incrementing the version in ada-mode.el header.

Then users will see the new version when they next do 'list-packages',
and can install from there.

What would that process look like if I followed your approach?

Part of the point of ELPA is to make this process as easy as possible;
it seems a good design to me.

>> >> - we're not seriously affected by bugs in GNU ELPA packages since they
>> >> can be fixed and released independently.
>> > This is actually a disadvantage: it contributes to the lower quality
>> > of their code.
>> 
>> I feel like we're already stretched pretty thin, so adding more packages
>> into Emacs's core would probably not improve those packages by much, and
>> if it does, it'd probably be to the detriment of others.

+1

I find it _much_ easier to fix bugs in Ada mode, now that it is
somewhat independent of Emacs core.

I realize that means I'm not working on Emacs core (except when Ada mode
is directly affected by a bug/lack of feature), but I would not be anyway.

>> >> - the maintainer of `foo' might not like to have to download a 300MB
>> >> repository to hack on her 300-lines package.
>> > ELPA is currently 52MB on my disk, which is not negligible (if 300MB
>> > aren't).  Does this mean you will change your mind when ELPA hits
>> > 100MB?
>> 
>> Indeed, and that is also a problem.  For that reason, more of the newer
>> packages are added as branches rather than as directories in the main
>> branch.  This mean you don't need the whole repository to hack on them.
>
> I have 1.5TB of disk storage on my main development machine.  I refuse
> to believe that these small figures make a difference to someone these
> days.

For me, the problem with having Ada mode directly in ELPA is reviewing
the git commit log to see if anyone else edited the Ada mode code. I
ended up skipping that, and relying on ediff with my own repository (I
don't find it convenient to use the ELPA repository directly for
development; for one thing, I prefer monotone over git). 

I'm not clear on how to "put a package on an external branch" (yes, I
have read Stefan's posts on that; they are too cryptic), but perhaps I
should try that.

-- 
-- Stephe



reply via email to

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