emacs-devel
[Top][All Lists]
Advanced

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

Re: Proposal for an Emacs User Survey


From: Thibaut Verron
Subject: Re: Proposal for an Emacs User Survey
Date: Mon, 19 Oct 2020 18:42:48 +0200

Le lun. 19 oct. 2020 à 17:48, Drew Adams <drew.adams@oracle.com> a écrit :
>
> > MELPA to a large part consists of a database of "recipes", one for each
> > package that it builds and distributes. This tag can be put inside
> > recipes, and thus be controlled by MELPA maintainers, and not by the
> > packages authors themselves.
> >
> > If we provide some well-defined criteria for such tags, and pick a
> > neutral-enough name, I don't see why the MELPA maintainers (who are
> > quite reasonable people IME) wouldn't go for it.
>
> Just a minor comment/question about this, which
> I think would be the first time such a thing
> would be happening:
>
> Do we really want to set a precedent that
> someone other than the code author fiddles with
> their code, adding comments or whatever?
>
> Sure, the maintainers of a repo are, in a way,
> administrators.  But should such administrators
> be changing source code?  Adding other code or
> whatever, to administer, label, treat, etc. the
> code is, at least conceptually, different from
> changing the source code itself.
>
> No, adding a field/tag in a comment is not a big
> deal.  And yes, GPL code is open to modification.
>
> Still, is this a good door to open?

I'm not sure to understand the question. The recipes are stored in the
Melpa repository, so the maintainers of the repo are really the
maintainers of the source code (the recipes).

The recipes are written by the authors of the package, by forking and
filing a request to merge into the Melpa repository.

So if the administrators of Melpa agree to it, they are entirely in
their prerogative to alter the recipes provided by the users in their
code (list of recipes). It's not really different from adding a
comment to clarify a bug fix by an external contributor after the code
is merged.

They would not be modifying the code of the packages themselves, of course.



reply via email to

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