emacs-devel
[Top][All Lists]
Advanced

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

Re: package and testing rant (was Re: package.el, auto-installation, and


From: Phillip Lord
Subject: Re: package and testing rant (was Re: package.el, auto-installation, and auto-removal)
Date: Fri, 14 Nov 2014 11:04:24 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Nic Ferrier <address@hidden> writes:

> address@hidden (Phillip Lord) writes:
>
>> Nic Ferrier <address@hidden> writes:
>>> The centralization isn't really a problem right now you think. But I bet
>>> it is. You're making people work inside a source tree that doesn't
>>> belong to them and you're constraining the technical content they put
>>> there.
>>>
>>> You're also inviting people to break the Makefile because they want
>>> their own build.
>>>
>>> You're also inviting people to check in non-working code.
>>>
>>> You might say "these things have not happened yet". But that's because
>>> there are very few ELPA authors so far. Maybe one of the reasons there
>>> are so few ELPA authors is that it's weird.
>>
>>
>> There is some truth in this. I feel rather more nervous commting into
>> ELPA because it contains so many pieces of work from others. With my own
>> repo's, that's fine. If I screw things up, then it's my problem.
>
> Kinda implies there isn't any truth in the rest of it :-(

But only kinda implies, not actually implies.

For the record, I only sort of agree with you. First, I think you are
overplaying things somewhat. I can see the issues that you are talking
about, but I am not certain how common they are. If it's just org-mode
and maybe semantic that a complicated build, then perhaps special case
treatment is the best way forward.

Second, I do not think that the problem is that elpa.git is a source
archive, or that the artifacts are build away from the developer.
It is a worry that it may not be so easy to reproduce. So, for example,
with MELPA, I can pull down the whole thing (small at 17Mb, because it
only contains recipies). Then

make recipies/pabbrev

builds my package. The point is that the build is *replicable* from the
source; I can do it locally, even though normally, I do not.

Finally, I think your complaints about elpa.git are also reasonable; I
would prefer to be using my own repo for my packages. Getting everything
set up on an ELPA branch has not been trivial (and is still not entirely
working for reasons I cannot figure). However, I can appreciate Stefan's
position. He has already made some changes to my packages and
improved them. For me, the cost of raising my own activation energy in
contributing to ELPA is probably worth the benefit of lowering his.

Phil




reply via email to

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