[Top][All Lists]

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

Re: Adding packages to ELPA

From: Stefan Monnier
Subject: Re: Adding packages to ELPA
Date: Fri, 19 Sep 2014 14:13:34 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

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

But if you want to make release 3.4 with some new changes, you first
need to commit those changes, and if the trunk is frozen you can't do
this commit so easily.

Can it be done, yes.  But having the package be completely separate makes
things a lot easier.

Another aspect of GNU ELPA is that people get to discover the new
packages as they get added (if they check the ELPA archive regularly, or
if they read gnu.emacs.sources), as opposed to having them smashed
together, drowned in the large list of changes in etc/NEWS.

> Maybe you are right, but we will not know that unless we try.  I bet
> your feeling of being stretched thin is not based on facts, just on
> gut feelings.  I'm not really sure about that.

I know *I*'m stretched really thin.

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

Nowadays it's very common to never use "just the source" but "the source
with its VCS metadata".  Everywhere.  So if your config uses package
Foo, you'll want to have that package's VCS metadata in your config.
That gets copied to every one of your various accounts.  Some of those
accounts may have significant quota constraints, or be on rather
smallish rented virtual machines, or on a small home router with no HDD.
Can those cases accommodate 300MB of extra stuff?  Possibly, but you may
have to choose between that and something else.

Also, if you have N such packages.  Are you going to use up 300MB * N of
disk space?  That can become more problematical, so you'll have to go
through extra hoops to try and share that redundant data, which you
wouldn't need to do if they were separate to start with.

And of course in some situations, the bandwidth requirement, or the
processing requirements (it takes much longer to go through that 300MB
of metadata) is more problematical than the disk space itself.  But the
argument is the same.


reply via email to

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