[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Improving GNU ELPA
From: |
Stefan Monnier |
Subject: |
Re: Improving GNU ELPA |
Date: |
Tue, 18 Jul 2017 13:26:34 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) |
>> There are no real rules, here, other than the fact that elpa.git may be
>> modified by us directly, so if the maintainer decides to keep the
>> "upstream" elsewhere it's his responsibility to deal with the fallout
> This bit I don't like!
You're not alone, so in general we should try to avoid it.
> What sort of commits do you do locally?
Not sure what you mean by "locally". Do you mean, what kinds of commits
do we want to install directly into elpa.git (for those cases where the
upstream is elsewhere)?
Typically things like incorrect copyright notices or compilation breakage.
> Would scripting something to branch, and do git-request-pull to the
> upstream be a substitute?
Nowadays, most of time I send a patch via email to the maintainer rather
than committing directly. It's more tedious but since I now do much less
janitorial work on elpa.git code it's OK.
Stefan
- Re: Improving GNU ELPA, (continued)
- Re: Improving GNU ELPA, Richard Stallman, 2017/07/18
- Re: Improving GNU ELPA, Phillip Lord, 2017/07/18
- Re: Improving GNU ELPA, Richard Stallman, 2017/07/18
- Re: Improving GNU ELPA, Phillip Lord, 2017/07/19
- Re: Improving GNU ELPA, Richard Stallman, 2017/07/18
- Re: Improving GNU ELPA, Stefan Monnier, 2017/07/18
- Re: Improving GNU ELPA, Phillip Lord, 2017/07/18
- Re: Improving GNU ELPA,
Stefan Monnier <=
- Re: Improving GNU ELPA, Phillip Lord, 2017/07/19
- Re: Improving GNU ELPA, Richard Stallman, 2017/07/23
- Re: Improving GNU ELPA, Phillip Lord, 2017/07/24
Re: Adding advisory notification for non-ELPA package.el downloads, Paul Rankin, 2017/07/20