ELPA contributions?

ELPA contributions?

[David Kastrup]

I've taken a look at elpa.gnu.org and the README referenced in there,
and at lists.gnu.org.  There does not appear to be a discussion list for
ELPA, and the README just contains the technical details of uploading
material to ELPA (it's not really clear when to choose an external
branch).  There are no obvious submission addresses or anything like
that.

One just dumps his stuff in there in case one happens to be an Emacs
developer?

-- 
David Kastrup

Re: ELPA contributions?

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

The takeaway message is: Yes the readme could use some improvements.

On 9 Oct 2015 9:32 am, "David Kastrup" <dak@gnu.org> wrote:
> I've taken a look at elpa.gnu.org and the README referenced in there,
> and at lists.gnu.org.  There does not appear to be a discussion list for
> ELPA,

There isn't. Elpa stuff is discussed on the emacs lists. But the Readme
should certainly say that.

> and the README just contains the technical details of uploading
> material to ELPA (it's not really clear when to choose an external
> branch).

Yes, that needs to be clarified too. The idea is to just use a subtree,
unless you _know_ you want an external branch for some reason.

> There are no obvious submission addresses or anything like
> that.

Yes, that should just be Emacs-devel as well.

> One just dumps his stuff in there in case one happens to be an Emacs
> developer?

I don't understand this sentence. Dumps their stuff on elpa.git? What does
this have to do with being a developer?

Cheers,
Artur

[-- Attachment #2: Type: text/html, Size: 1392 bytes --]

Re: ELPA contributions?

[David Kastrup]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

[...]
>
>> One just dumps his stuff in there in case one happens to be an Emacs
>> developer?
>
> I don't understand this sentence. Dumps their stuff on elpa.git?

Yes.

> What does this have to do with being a developer?

Push access.

-- 
David Kastrup

Re: ELPA contributions?

[David Kastrup]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> The takeaway message is: Yes the readme could use some improvements.
>
> On 9 Oct 2015 9:32 am, "David Kastrup" <dak@gnu.org> wrote:
>> I've taken a look at elpa.gnu.org and the README referenced in there,
>> and at lists.gnu.org.  There does not appear to be a discussion list for
>> ELPA,
>
> There isn't. Elpa stuff is discussed on the emacs lists. But the Readme
> should certainly say that.
>
>> and the README just contains the technical details of uploading
>> material to ELPA (it's not really clear when to choose an external
>> branch).
>
> Yes, that needs to be clarified too. The idea is to just use a subtree,
> unless you _know_ you want an external branch for some reason.
>
>> There are no obvious submission addresses or anything like
>> that.
>
> Yes, that should just be Emacs-devel as well.

That does not really appear to match the realities.  There are a host of
commits in ELPA coming from known Emacs developers (well, push
access...) for projects I never heard of on the developer list.  And
since ELPA contributions (if I understood correctly) require an Emacs
copyright assignment anyway and that is coupled with commit access
fairly often, there really is a strong appearance of "just write to ELPA
if you think you know what you are doing".

And if I don't hear anything about the prospected file/project I posted
here, that's likely what I'll end up doing.

Still feels a bit unsual, though.

-- 
David Kastrup

Re: ELPA contributions?

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]

On 10 Oct 2015 8:00 am, "David Kastrup" <dak@gnu.org> wrote:
> >> There are no obvious submission addresses or anything like
> >> that.
> >
> > Yes, that should just be Emacs-devel as well.
>
> That does not really appear to match the realities.  There are a host of
> commits in ELPA coming from known Emacs developers (well, push
> access...) for projects I never heard of on the developer list.

There's no enforced submission process yet. But if you want to submit a
package for consideration (because you're new or you don't know if it's
worth it) then emacs-devel is the place. That's the current reality.

> And
> since ELPA contributions (if I understood correctly) require an Emacs
> copyright assignment anyway and that is coupled with commit access
> fairly often, there really is a strong appearance of "just write to ELPA
> if you think you know what you are doing".

Pretty much. Yes, it's unusual. I suppose the number of contributors has
been small, so it's worked so far (but I'm fairly new here so it's just my
impression).

We could require that people send new packages to emacs-devel before
pushing them. These wouldn't be used to veto/approve packages, it would
most be an announcement/feedback-request/ensure-it-doesnt-violate-fsf-rules
thing.

- if we're going to enforce a submission

[-- Attachment #2: Type: text/html, Size: 1657 bytes --]

Re: ELPA contributions?

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 190 bytes --]

On 10 Oct 2015 11:24 pm, "Artur Malabarba" <bruce.connor.am@gmail.com>
wrote:
> - if we're going to enforce a submission

Sorry. Ignore this senseless last line in my email. It's late here.

[-- Attachment #2: Type: text/html, Size: 307 bytes --]

Re: ELPA contributions?

[Phillip Lord]

Artur Malabarba <bruce.connor.am@gmail.com> writes:
>> and the README just contains the technical details of uploading
>> material to ELPA (it's not really clear when to choose an external
>> branch).
>
> Yes, that needs to be clarified too. The idea is to just use a subtree,
> unless you _know_ you want an external branch for some reason.


Well, here is the interesting bit. As far as I can tell, a subtree IS an
external (sort of). AFAICT, for instance, "ack" is a subtree (which I
think means, it has been added by the "git subtree" command, although I
don't know how to test this), while "auctex" is a :external. But both
are identified in externals-list. While ace-window is neither.

All fairly confusing really. I've been using :external branches for my
packages, but I think possibly I should have been using subtrees. I used
to not use externals at all (i.e. neither an :external or :subtree), but
that didn't work.

The MELPA process (i.e. submit a recipe) is much more straight-forward.

Still, having said all of this, I have a workflow which works using
:external branches, and which works whether or not you have commit
access to the "main" repository. I'll try and write this up at some
point. I'd love someone to do the same for subtrees, so I can see
whether that would have been the right way to go in the first place.

Phil

Re: ELPA contributions?

[Eric Abrahamsen]

phillip.lord@russet.org.uk (Phillip Lord) writes:

> Artur Malabarba <bruce.connor.am@gmail.com> writes:
>>> and the README just contains the technical details of uploading
>>> material to ELPA (it's not really clear when to choose an external
>>> branch).
>>
>> Yes, that needs to be clarified too. The idea is to just use a subtree,
>> unless you _know_ you want an external branch for some reason.
>
>
> Well, here is the interesting bit. As far as I can tell, a subtree IS an
> external (sort of). AFAICT, for instance, "ack" is a subtree (which I
> think means, it has been added by the "git subtree" command, although I
> don't know how to test this), while "auctex" is a :external. But both
> are identified in externals-list. While ace-window is neither.
>
> All fairly confusing really. I've been using :external branches for my
> packages, but I think possibly I should have been using subtrees. I used
> to not use externals at all (i.e. neither an :external or :subtree), but
> that didn't work.
>
> The MELPA process (i.e. submit a recipe) is much more straight-forward.
>
> Still, having said all of this, I have a workflow which works using
> :external branches, and which works whether or not you have commit
> access to the "main" repository. I'll try and write this up at some
> point. I'd love someone to do the same for subtrees, so I can see
> whether that would have been the right way to go in the first place.

Here's from my notes on how I'm supposed to merge the Gnorb package into
ELPA. I started using git subtree because it seemed conceptually like
the right thing. It turned out to be pretty complicated (because I
didn't understand it well) and I still feel a sense of dread every time
I go to update the package. I wish there were a simpler way.

I added a local git repo as a remote ("gnorb") to the elpa repo. Pulling
from the external repo goes:

git fetch gnorb
git subtree pull --squash --prefix=packages/gnorb gnorb master

Pushing from the ELPA repo to the gnorb remote (I tried this because
Stefan made some changes directly in the packages):

git subtree push --squash --prefix=packages/gnorb gnorb master

This is followed by an expletive-filled paragraph of notes. I'm not sure
pushing to the remote ever actually worked. I also tried something
called "split branch", which barfed several pages of output into my
shell, to what end I'm still not sure.

In the end, when I wanted to get changes from ELPA into my external
repo, I think it worked okay to simply throw a patch over and apply it
there. There's no actual correspondence between commit SHAs in ELPA and
the remote, so simply having the files in the same state is good enough.

But basically it felt like I was going to have to learn all of the
internals of git to do this with any sort of confidence.

Eric

Re: ELPA contributions?

[Phillip Lord]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>> Still, having said all of this, I have a workflow which works using
>> :external branches, and which works whether or not you have commit
>> access to the "main" repository. I'll try and write this up at some
>> point. I'd love someone to do the same for subtrees, so I can see
>> whether that would have been the right way to go in the first place.
>
> Here's from my notes on how I'm supposed to merge the Gnorb package into
> ELPA. I started using git subtree because it seemed conceptually like
> the right thing. It turned out to be pretty complicated (because I
> didn't understand it well) and I still feel a sense of dread every time
> I go to update the package. I wish there were a simpler way.
>
> I added a local git repo as a remote ("gnorb") to the elpa repo. Pulling
> from the external repo goes:
>
> git fetch gnorb
> git subtree pull --squash --prefix=packages/gnorb gnorb master
>
> Pushing from the ELPA repo to the gnorb remote (I tried this because
> Stefan made some changes directly in the packages):
>
> git subtree push --squash --prefix=packages/gnorb gnorb master
>
> This is followed by an expletive-filled paragraph of notes. I'm not sure
> pushing to the remote ever actually worked. I also tried something
> called "split branch", which barfed several pages of output into my
> shell, to what end I'm still not sure.

Hmmm.

Well, with dash, I've used an external branch. I've set up remotes like so.

elpa	git.sv.gnu.org:/srv/git/emacs/elpa.git (fetch)
elpa	git.sv.gnu.org:/srv/git/emacs/elpa.git (push)
origin	git@github.com:magnars/dash.el.git (fetch)
origin	git@github.com:magnars/dash.el.git (push)
pwl	git@github.com:phillord/dash.el.git (fetch)
pwl	git@github.com:phillord/dash.el.git (push)


Now, I have commit access to ELPA, but read-only access to github.

My workflow (which I normally do in magit, so the commands here are
approximations!) is something like this.

To get changes from github to ELPA,

git pull origin master
git push -v --dry-run elpa master:refs/heads/externals/dash

(without the dry-run!).

Then to get changes from ELPA back to github I do:

git branch fix/something-from-elpa
git pull elpa externals/dash
git push pwl

Then I can open a PR from pwl to dash, which gets merged in. The commits
all match up so the ELPA change gets pulled then pushed to github, then
eventually pulled then pushed from github back to ELPA, but it all works.

At least so far. I've done the last bit once so far. I have no idea what
to do if Magnar ever bounces a PR.

I use a similar workflow for pabbrev, except that I have write access
both sides.

> In the end, when I wanted to get changes from ELPA into my external
> repo, I think it worked okay to simply throw a patch over and apply it
> there. There's no actual correspondence between commit SHAs in ELPA and
> the remote, so simply having the files in the same state is good enough.
>
> But basically it felt like I was going to have to learn all of the
> internals of git to do this with any sort of confidence.


I share the same feeling. The bit that scares me is pushing to ELPA.
Everything else is disposable. If I pull the wrong thing (like
elpa/master) to local, then I can just delete and start again. If I push
the wrong thing to phillord/dash.el that's more of a pain, but not a
disaster. But if I push my local master to the elpa master branch
(rather than externals) I do not know what will happen, but I suspect it
will be bad.

Phil

Re: ELPA contributions?

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 984 bytes --]

On 12 Oct 2015 9:54 pm, "Phillip Lord" <phillip.lord@russet.org.uk> wrote:
> > But basically it felt like I was going to have to learn all of the
> > internals of git to do this with any sort of confidence.
>
>
> I share the same feeling. The bit that scares me is pushing to ELPA.
> Everything else is disposable. If I pull the wrong thing (like
> elpa/master) to local, then I can just delete and start again. If I push
> the wrong thing to phillord/dash.el that's more of a pain, but not a
> disaster. But if I push my local master to the elpa master branch
> (rather than externals) I do not know what will happen, but I suspect it
> will be bad.

This is git. It's pretty hard to mess up.

In particular, you can't push anything that's not a fast forward unless you
--force, and you usually can't --force push to master. Again, I'm not at
the pc ATM, but I'm pretty sure that's the case for elpa.git. Hell,
emacs.git won't even let me push if it doesn't like the commit message.

[-- Attachment #2: Type: text/html, Size: 1242 bytes --]

Re: ELPA contributions?

[Phillip Lord]

Artur Malabarba <bruce.connor.am@gmail.com> writes:
>> I share the same feeling. The bit that scares me is pushing to ELPA.
>> Everything else is disposable. If I pull the wrong thing (like
>> elpa/master) to local, then I can just delete and start again. If I push
>> the wrong thing to phillord/dash.el that's more of a pain, but not a
>> disaster. But if I push my local master to the elpa master branch
>> (rather than externals) I do not know what will happen, but I suspect it
>> will be bad.
>
> This is git. It's pretty hard to mess up.

Git is many things but "pretty hard to mess up" is not one of them, in
my experience.

> In particular, you can't push anything that's not a fast forward unless you
> --force, and you usually can't --force push to master. Again, I'm not at
> the pc ATM, but I'm pretty sure that's the case for elpa.git. Hell,
> emacs.git won't even let me push if it doesn't like the commit message.

That's reassuring anyway, although I don't know a good way of testing it
(safely!).

Phil

Re: ELPA contributions?

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 3562 bytes --]

All I ever do is "remote add, subtree add, subtree pull" to add a new
package; or just subtree pull to update a package. This is pretty much what
you're doing, except I don't fetch nor squash.

When someone edits a package on the elpa repo, I just copy the changes over
to my remote (no git commands). It's just simpler this way.

All of this should really be better explained on the readme. I remember I
felt a little lost the first time I was doing it. If anyone would like to
document these steps a bit better I would be thoroughly grateful.

Best,
Artur
On 12 Oct 2015 5:00 pm, "Eric Abrahamsen" <eric@ericabrahamsen.net> wrote:
>
> phillip.lord@russet.org.uk (Phillip Lord) writes:
>
> > Artur Malabarba <bruce.connor.am@gmail.com> writes:
> >>> and the README just contains the technical details of uploading
> >>> material to ELPA (it's not really clear when to choose an external
> >>> branch).
> >>
> >> Yes, that needs to be clarified too. The idea is to just use a subtree,
> >> unless you _know_ you want an external branch for some reason.
> >
> >
> > Well, here is the interesting bit. As far as I can tell, a subtree IS an
> > external (sort of). AFAICT, for instance, "ack" is a subtree (which I
> > think means, it has been added by the "git subtree" command, although I
> > don't know how to test this), while "auctex" is a :external. But both
> > are identified in externals-list. While ace-window is neither.
> >
> > All fairly confusing really. I've been using :external branches for my
> > packages, but I think possibly I should have been using subtrees. I used
> > to not use externals at all (i.e. neither an :external or :subtree), but
> > that didn't work.
> >
> > The MELPA process (i.e. submit a recipe) is much more straight-forward.
> >
> > Still, having said all of this, I have a workflow which works using
> > :external branches, and which works whether or not you have commit
> > access to the "main" repository. I'll try and write this up at some
> > point. I'd love someone to do the same for subtrees, so I can see
> > whether that would have been the right way to go in the first place.
>
> Here's from my notes on how I'm supposed to merge the Gnorb package into
> ELPA. I started using git subtree because it seemed conceptually like
> the right thing. It turned out to be pretty complicated (because I
> didn't understand it well) and I still feel a sense of dread every time
> I go to update the package. I wish there were a simpler way.
>
> I added a local git repo as a remote ("gnorb") to the elpa repo. Pulling
> from the external repo goes:
>
> git fetch gnorb
> git subtree pull --squash --prefix=packages/gnorb gnorb master
>
> Pushing from the ELPA repo to the gnorb remote (I tried this because
> Stefan made some changes directly in the packages):
>
> git subtree push --squash --prefix=packages/gnorb gnorb master
>
> This is followed by an expletive-filled paragraph of notes. I'm not sure
> pushing to the remote ever actually worked. I also tried something
> called "split branch", which barfed several pages of output into my
> shell, to what end I'm still not sure.
>
> In the end, when I wanted to get changes from ELPA into my external
> repo, I think it worked okay to simply throw a patch over and apply it
> there. There's no actual correspondence between commit SHAs in ELPA and
> the remote, so simply having the files in the same state is good enough.
>
> But basically it felt like I was going to have to learn all of the
> internals of git to do this with any sort of confidence.
>
> Eric
>
>

[-- Attachment #2: Type: text/html, Size: 4493 bytes --]

Re: ELPA contributions?

[Eric Abrahamsen]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> All I ever do is "remote add, subtree add, subtree pull" to add a new
> package; or just subtree pull to update a package. This is pretty much
> what you're doing, except I don't fetch nor squash. 
>
> When someone edits a package on the elpa repo, I just copy the changes
> over to my remote (no git commands). It's just simpler this way. 
>
> All of this should really be better explained on the readme. I
> remember I felt a little lost the first time I was doing it. If anyone
> would like to document these steps a bit better I would be thoroughly
> grateful. 

I really regret squashing: I think I only did it because of some vague
sense that it would be more hygienic. Fairly nonsensical, but I don't
think it's possible, or practical, to unsquash at this point. For the
sake of simplicity, I think it would be good if the README recommends
not squashing.

> Best, 
> Artur 
> On 12 Oct 2015 5:00 pm, "Eric Abrahamsen" <eric@ericabrahamsen.net>
> wrote:
>>
>> phillip.lord@russet.org.uk (Phillip Lord) writes:
>>
>> > Artur Malabarba <bruce.connor.am@gmail.com> writes:
>> >>> and the README just contains the technical details of uploading
>> >>> material to ELPA (it's not really clear when to choose an
> external
>> >>> branch).
>> >>
>> >> Yes, that needs to be clarified too. The idea is to just use a
> subtree,
>> >> unless you _know_ you want an external branch for some reason.
>> >
>> >
>> > Well, here is the interesting bit. As far as I can tell, a subtree
> IS an
>> > external (sort of). AFAICT, for instance, "ack" is a subtree
> (which I
>> > think means, it has been added by the "git subtree" command,
> although I
>> > don't know how to test this), while "auctex" is a :external. But
> both
>> > are identified in externals-list. While ace-window is neither.
>> >
>> > All fairly confusing really. I've been using :external branches
> for my
>> > packages, but I think possibly I should have been using subtrees.
> I used
>> > to not use externals at all (i.e. neither an :external or :
> subtree), but
>> > that didn't work.
>> >
>> > The MELPA process (i.e. submit a recipe) is much more
> straight-forward.
>> >
>> > Still, having said all of this, I have a workflow which works
> using
>> > :external branches, and which works whether or not you have commit
>> > access to the "main" repository. I'll try and write this up at
> some
>> > point. I'd love someone to do the same for subtrees, so I can see
>> > whether that would have been the right way to go in the first
> place.
>>
>> Here's from my notes on how I'm supposed to merge the Gnorb package
> into
>> ELPA. I started using git subtree because it seemed conceptually
> like
>> the right thing. It turned out to be pretty complicated (because I
>> didn't understand it well) and I still feel a sense of dread every
> time
>> I go to update the package. I wish there were a simpler way.
>>
>> I added a local git repo as a remote ("gnorb") to the elpa repo.
> Pulling
>> from the external repo goes:
>>
>> git fetch gnorb
>> git subtree pull --squash --prefix=packages/gnorb gnorb master
>>
>> Pushing from the ELPA repo to the gnorb remote (I tried this because
>> Stefan made some changes directly in the packages):
>>
>> git subtree push --squash --prefix=packages/gnorb gnorb master
>>
>> This is followed by an expletive-filled paragraph of notes. I'm not
> sure
>> pushing to the remote ever actually worked. I also tried something
>> called "split branch", which barfed several pages of output into my
>> shell, to what end I'm still not sure.
>>
>> In the end, when I wanted to get changes from ELPA into my external
>> repo, I think it worked okay to simply throw a patch over and apply
> it
>> there. There's no actual correspondence between commit SHAs in ELPA
> and
>> the remote, so simply having the files in the same state is good
> enough.
>>
>> But basically it felt like I was going to have to learn all of the
>> internals of git to do this with any sort of confidence.
>>
>> Eric
>>
>>

Re: ELPA contributions?

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Artur Malabarba <bruce.connor.am@gmail.com> writes:
>
>> All I ever do is "remote add, subtree add, subtree pull" to add a new
>> package; or just subtree pull to update a package. This is pretty much
>> what you're doing, except I don't fetch nor squash. 
>>
>> When someone edits a package on the elpa repo, I just copy the changes
>> over to my remote (no git commands). It's just simpler this way. 
>>
>> All of this should really be better explained on the readme. I
>> remember I felt a little lost the first time I was doing it. If anyone
>> would like to document these steps a bit better I would be thoroughly
>> grateful. 
>
> I really regret squashing: I think I only did it because of some vague
> sense that it would be more hygienic. Fairly nonsensical, but I don't
> think it's possible, or practical, to unsquash at this point. For the
> sake of simplicity, I think it would be good if the README recommends
> not squashing.

Also, Stefan's original recommendation was to just develop the package
in ELPA: no remote.

I think this could be a more viable option if debbugs integrated with
ELPA a bit better. Personally, I wanted Github a tiny bit for the fame
and the glory, but mostly because of the issue tracking. Other people
probably make more use of Github's functionality (Phil mentioned pull
requests, etc), but in my case, if I got an automatic email anytime
anyone reported an Emacs bug with "gnorb" in the package header...

Hang on, back up. If `report-emacs-bug' prompted the user for a package
(with completion), and then I was automatically emailed with any bug
reports filed against my package(s) (where I'm in the Maintainer
header), and then I could continue that back-and-forth via debbugs, most
of the allure of Github would be gone for me, and I'd probably just do
the development within ELPA.

More than 2 cents by now,

Eric

Re: ELPA contributions?

[Phillip Lord]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>> All of this should really be better explained on the readme. I
>>> remember I felt a little lost the first time I was doing it. If anyone
>>> would like to document these steps a bit better I would be thoroughly
>>> grateful. 
>>
>> I really regret squashing: I think I only did it because of some vague
>> sense that it would be more hygienic. Fairly nonsensical, but I don't
>> think it's possible, or practical, to unsquash at this point. For the
>> sake of simplicity, I think it would be good if the README recommends
>> not squashing.

If I understand, a git subtree squash is not like a normal rebase; it
does actually know about the commits that were squashed, as opposed to
rewriting them like a rebase squash.


> Also, Stefan's original recommendation was to just develop the package
> in ELPA: no remote.
>
> I think this could be a more viable option if debbugs integrated with
> ELPA a bit better. Personally, I wanted Github a tiny bit for the fame
> and the glory, but mostly because of the issue tracking. Other people
> probably make more use of Github's functionality (Phil mentioned pull
> requests, etc),

For my own packages, I'd moved them from mercurial on google code to
github shortly before, so shifting the development to ELPA didn't seem
like a good way forward. For dash, it just reflects the reality -- it
was already developed on github and wasn't going to move.

> but in my case, if I got an automatic email anytime anyone reported an
> Emacs bug with "gnorb" in the package header...
>
> Hang on, back up. If `report-emacs-bug' prompted the user for a package
> (with completion), and then I was automatically emailed with any bug
> reports filed against my package(s) (where I'm in the Maintainer
> header), and then I could continue that back-and-forth via debbugs, most
> of the allure of Github would be gone for me, and I'd probably just do
> the development within ELPA.

All of that would help.

Phil

Re: ELPA contributions?

[Artur Malabarba]

2015-10-13 10:35 GMT+01:00 Phillip Lord <phillip.lord@russet.org.uk>:
>
> If I understand, a git subtree squash is not like a normal rebase; it
> does actually know about the commits that were squashed, as opposed to
> rewriting them like a rebase squash.

Perhaps. But still, people should not squash to elpa.git. It has
downsides with no real benefits (that I know of).

- If your package is part of elpa.git, then its commit messages should
be part of elpa.git's commit messages (even if the package is being
primarily developed somewhere else).
- The build-scripts can generate package change-logs from commit messages.
- If someone is trying to `git-blame' one of your package files,
having squashed is only going to complicate matters.

I've added some better instructions to the Readme, but there's still
much that needs to be done to it.

> > Also, Stefan's original recommendation was to just develop the package
> > in ELPA: no remote.
> >
> > I think this could be a more viable option if debbugs integrated with
> > ELPA a bit better. Personally, I wanted Github a tiny bit for the fame
> > and the glory, but mostly because of the issue tracking. Other people
> > probably make more use of Github's functionality (Phil mentioned pull
> > requests, etc),
>
> For my own packages, I'd moved them from mercurial on google code to
> github shortly before, so shifting the development to ELPA didn't seem
> like a good way forward. For dash, it just reflects the reality -- it
> was already developed on github and wasn't going to move.
>
> > but in my case, if I got an automatic email anytime anyone reported an
> > Emacs bug with "gnorb" in the package header...
> >
> > Hang on, back up. If `report-emacs-bug' prompted the user for a package
> > (with completion), and then I was automatically emailed with any bug
> > reports filed against my package(s) (where I'm in the Maintainer
> > header), and then I could continue that back-and-forth via debbugs, most
> > of the allure of Github would be gone for me, and I'd probably just do
> > the development within ELPA.
>
> All of that would help.

All agreed. Some packages are always going to prefer being primarily
on Github. But having a better bug-tracker here would make it so that
fewer packages feel obligated to be on Github. For let-alist, for
instance, I wanted to develop the package here directly, so I created
a github repo with no source just for the issue tracker..

Re: ELPA contributions?

[Eric Abrahamsen]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> 2015-10-13 10:35 GMT+01:00 Phillip Lord <phillip.lord@russet.org.uk>:
>>
>> If I understand, a git subtree squash is not like a normal rebase; it
>> does actually know about the commits that were squashed, as opposed to
>> rewriting them like a rebase squash.
>
> Perhaps. But still, people should not squash to elpa.git. It has
> downsides with no real benefits (that I know of).
>
> - If your package is part of elpa.git, then its commit messages should
> be part of elpa.git's commit messages (even if the package is being
> primarily developed somewhere else).
> - The build-scripts can generate package change-logs from commit messages.
> - If someone is trying to `git-blame' one of your package files,
> having squashed is only going to complicate matters.
>
> I've added some better instructions to the Readme, but there's still
> much that needs to be done to it.
>
>> > Also, Stefan's original recommendation was to just develop the package
>> > in ELPA: no remote.
>> >
>> > I think this could be a more viable option if debbugs integrated with
>> > ELPA a bit better. Personally, I wanted Github a tiny bit for the fame
>> > and the glory, but mostly because of the issue tracking. Other people
>> > probably make more use of Github's functionality (Phil mentioned pull
>> > requests, etc),
>>
>> For my own packages, I'd moved them from mercurial on google code to
>> github shortly before, so shifting the development to ELPA didn't seem
>> like a good way forward. For dash, it just reflects the reality -- it
>> was already developed on github and wasn't going to move.
>>
>> > but in my case, if I got an automatic email anytime anyone reported an
>> > Emacs bug with "gnorb" in the package header...
>> >
>> > Hang on, back up. If `report-emacs-bug' prompted the user for a package
>> > (with completion), and then I was automatically emailed with any bug
>> > reports filed against my package(s) (where I'm in the Maintainer
>> > header), and then I could continue that back-and-forth via debbugs, most
>> > of the allure of Github would be gone for me, and I'd probably just do
>> > the development within ELPA.
>>
>> All of that would help.
>
> All agreed. Some packages are always going to prefer being primarily
> on Github. But having a better bug-tracker here would make it so that
> fewer packages feel obligated to be on Github. For let-alist, for
> instance, I wanted to develop the package here directly, so I created
> a github repo with no source just for the issue tracker..

Who runs debbugs? How hard would it be to add a cc based on the
Maintainer header?

Re: ELPA contributions?

[Phillip Lord]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>> All agreed. Some packages are always going to prefer being primarily
>> on Github. But having a better bug-tracker here would make it so that
>> fewer packages feel obligated to be on Github. For let-alist, for
>> instance, I wanted to develop the package here directly, so I created
>> a github repo with no source just for the issue tracker..
>
> Who runs debbugs? How hard would it be to add a cc based on the
> Maintainer header?

Ironicaly, debbugs doesn't appear to be using debbugs at least according
to it's list of packages:

https://debbugs.gnu.org/Packages.html

Otherwise we could submit a bug/rfe there.

Phil

Re: ELPA contributions?

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 2106 bytes --]

On 12 Oct 2015 1:44 pm, "Phillip Lord" <phillip.lord@russet.org.uk> wrote:
>
> Well, here is the interesting bit. As far as I can tell, a subtree IS an
> external (sort of).

Let's not get lost in semantics. ;-)
A subtree is a local directory, which _can_ be updated by pulling from a
remote or can be edited locally. That's all there is to it. Call it what
you will.

> AFAICT, for instance, "ack" is a subtree (which I
> think means, it has been added by the "git subtree" command, although I
> don't know how to test this), while "auctex" is a :external. But both
> are identified in externals-list. While ace-window is neither.

Most likely ack is listed there by mistake. But I'm just guessing here,
can't check right now.

> All fairly confusing really. I've been using :external branches for my
> packages, but I think possibly I should have been using subtrees. I used
> to not use externals at all (i.e. neither an :external or :subtree), but
> that didn't work.
>
> The MELPA process (i.e. submit a recipe) is much more straight-forward.

True. But that wouldn't work for Gelpa. I believe the intention of the
current model was that Gelpa code is part of Emacs, and so anyone who can
make changes to Emacs should be able to make changes to Gelpa packages just
as easily. Stefan can probably confirm or deny this.

Having everyone on the same repo is not the cleanest way to achieve this,
but it's very doable and the disadvantages are acceptable.
A cleaner way would be to give each package its own savannah repo, but
that's probably much less doable and not worth the trouble (though the
technicalities of this are beyond me).

> Still, having said all of this, I have a workflow which works using
> :external branches, and which works whether or not you have commit
> access to the "main" repository. I'll try and write this up at some
> point. I'd love someone to do the same for subtrees, so I can see
> whether that would have been the right way to go in the first place.

If no one steps up, expanding the subtree explanation on the readme is on
my todo list with reasonably high priority.

[-- Attachment #2: Type: text/html, Size: 2568 bytes --]

Re: ELPA contributions?

[Phillip Lord]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> On 12 Oct 2015 1:44 pm, "Phillip Lord" <phillip.lord@russet.org.uk> wrote:
>>
>> Well, here is the interesting bit. As far as I can tell, a subtree IS an
>> external (sort of).
>
> Let's not get lost in semantics. ;-)
> A subtree is a local directory, which _can_ be updated by pulling from a
> remote or can be edited locally. That's all there is to it. Call it what
> you will.
>
>> AFAICT, for instance, "ack" is a subtree (which I
>> think means, it has been added by the "git subtree" command, although I
>> don't know how to test this), while "auctex" is a :external. But both
>> are identified in externals-list. While ace-window is neither.
>
> Most likely ack is listed there by mistake. But I'm just guessing here,
> can't check right now.

When I first looked at ELPA, I didn't know about git subtree. I still
don't know how to check whether a sub-directory has been added with
subtree. I just assumed that sub-directories in packages where that --
just part of one big repo. Which is why I used the external branches.

>> All fairly confusing really. I've been using :external branches for my
>> packages, but I think possibly I should have been using subtrees. I used
>> to not use externals at all (i.e. neither an :external or :subtree), but
>> that didn't work.
>>
>> The MELPA process (i.e. submit a recipe) is much more straight-forward.
>
> True. But that wouldn't work for Gelpa. I believe the intention of the
> current model was that Gelpa code is part of Emacs, and so anyone who can
> make changes to Emacs should be able to make changes to Gelpa packages just
> as easily. Stefan can probably confirm or deny this.

I understand that. Although, the MELPA set up works quite well for
upstream contributions also. You can clone all the repos on MELPA with
two commands (and a fair bit of patience).


> Having everyone on the same repo is not the cleanest way to achieve this,
> but it's very doable and the disadvantages are acceptable.
> A cleaner way would be to give each package its own savannah repo, but
> that's probably much less doable and not worth the trouble (though the
> technicalities of this are beyond me).
>
>> Still, having said all of this, I have a workflow which works using
>> :external branches, and which works whether or not you have commit
>> access to the "main" repository. I'll try and write this up at some
>> point. I'd love someone to do the same for subtrees, so I can see
>> whether that would have been the right way to go in the first place.
>
> If no one steps up, expanding the subtree explanation on the readme is on
> my todo list with reasonably high priority.

And I am happy to work on the :external explanation.

Phil