Adding git-modes to NonGNU ELPA

[phikal]

Hi,

I am working on adding a few major modes to NonGNU ELPA, including the major modes packaged in git-modes. As you certainly know from having have added Magit, ELPA requires a version tag in the package header. My question is therefore, would it be possible to add such a tag and update it for future versions?

[tarsius]

To quote git-modes.el's commentary:

;; Each mode is defined in its own library by the same name. Loading
;; `git-modes' causes all three libraries to be loaded, but you could
;; also load the libraries individually. On Melpa, the libraries are
;; distributed as separate packages.

It seems a bit silly that we distribute this as three packages on Melpa. We probably do that for "historic reasons".

If we add this to NonGNU Elpa, then we should probably switch to distributing just one package git-modes. I assume that someone who wants to use one of these modes would not mind having the others installed as well. In any case we should distribute it the same way on NGE and Melpa.

Switching from 3 to 1 package means that some existing users won't migrate for years to come, but I think that's okay because these packages aren't actually under active development. Mentioning @purcell in case he would like to comment.

[phikal]

That is fine, it will certainly be easier to package.

[purcell]

Yeah, separate packages don't seem necessary at all in this case.

[phikal]

Ok, in that case only git-modes.el would require a Version attribute.

[tarsius]

Please point me to the emacs-devel thread where you proposed to add git-modes. I searched but didn't find anything. Maybe you didn't mention it by name? Even so it might still make sense for me to reply to a message from a "add various packages" thread, instead of opening a new one.

[phikal]

I am currently using this thread to make suggestions, but have not formally proposed git-modes yet. The "elpa-packages" attachment in this message mentions git-modes, but my intention is to add git-modes along with a few other major modes in the near future.

[tarsius]

my intention is to add git-modes along with a few other major modes in the near future.

If you don't mind I would prefer to add it myself. In fact I would imagine that many authors would prefer to do it themselves. Proposing packages you are not involved with is fine, some authors might need a little shove to get it done, or even appreciate it.

But adding a package is only a little part of the work involved in having a package in [Non]GNU Elpa. Unlike with Melpa authors also have to actively keep the elpa.git/nongnu.git repository and the upstream repository up-to-date and in-sync.

Once a package is in [Non]GNU Elpa, there are two official repositories where it is published. IMO the design decisions that have lead to this are problematic but that's what we have to deal with now.

I have looked at a subset packages on GNU Elpa and for more than one third (sic!) the two repositories have differed in ways that require manual intervention. Furthermore it is easy to do the merging "wrong" (and Stefan has done that a few times already). There is no documentation how to deal with diverging histories.

I plan to publish some documentation(/opinion piece) on what the problems are and how I would deal with them. But I wasn't planning to do it soon.

So I have mixed feelings about the recent rush to add more packages. More packages is good -- more packages whose two publications more or less instantly start to diverge... not so much. That's why I am not so happy about your push to add more third-party packages: if a package author makes the move themselves, then they probably have thought about the involved version control work and feel up to the task. If they are "encouraged" by a third-party and (falsely) assured that the involved vc work is trivial, then that increases the odds of the package quickly diverging.

[phikal]

Jonas Bernoulli ***@***.***> writes:

> my intention is to add git-modes along with a few other major modes in the near future. If you don't mind I would prefer to add it myself.

That is absolutely fine.

In fact I would imagine that many authors would prefer to do it themselves. Proposing packages you are not involved with is fine, some authors might need a little shove to get it done, or even appreciate it.

Perhaps, but NonGNU ELPA has existed for a while now and there was little interest in adding packages that were already hosted on MELPA. To solve this chicken-and-egg problem something had to be done, to get things going.

But adding a package is only a little part of the work involved in having a package in [Non]GNU Elpa. Unlike with Melpa authors also have to actively keep the elpa.git/nongnu.git repository and the upstream repository up-to-date and in-sync.

I am not sure what you are referring to? NonGNU ELPA automatically synchronises packages. The main difference to MELPA from a maintainer-perspective is that stable versions are indicated by bumping the Version attribute, not a git tag, and that these are distributed by default (that might incentivise the maintainers to place more value of preparing stable releases). Other than that, nothing much *should* change.

Once a package is in [Non]GNU Elpa, there are two official repositories where it is published. IMO the design decisions that have lead to this are problematic but that's what we have to deal with now.

What problem do you have in mind?

I have looked at a subset packages on GNU Elpa and for **more than one third** (sic!) the two repositories have differed in ways that require manual intervention. Furthermore it is easy to do the merging "wrong" (and Stefan has done that a few times already). There is no documentation how to deal with diverging histories. I plan to publish some documentation(/opinion piece) on what the problems are and how I would deal with them. But I wasn't planning to do it soon.

I am sorry, but I am not sure what the issue is that you are talking about here. Could you give a concrete example?

So I have mixed feelings about the recent rush to add more packages. More packages is good -- more packages whose two publications more or less instantly start to diverge... not so much. That's why I am not so happy about your push to add more third-party packages: if a package author makes the move themselves, then they probably have thought about the involved version control work and feel up to the task. If they are "encouraged" by a third-party and (falsely) assured that the involved vc work is trivial, then that increases the odds of the package quickly diverging.

My apologies if you feel that way about this, but I hope I could explain where I am coming from. If there are issues I would like to take them seriously, and help solving them. Until then, I'll remove git-modes from my checklist.

…

-- Philip Kaludercic

[tarsius]

And I am bumping "write elpa.git documentation with examples of problematic state and concrete steps how to recover and avoid issues in the future" up on my todo list.

But the vague answer to most of your questions is "once the two repositories have diverged, then the automatic syncing does not work anymore". Also even if the repositories have not diverged yet, then syncing is only done in one direction, upstream to elpa.git. Many authors are not aware of that so they never pull any changes that (usually) Stefan has made to their packages in elpa.git, and Stefan doesn't have push rights to their upstream repositories so he cannot do anything about it either.

[phikal]

I see now what you are talking about, and understand the issue. Will keep it in mind.

…

-- Philip Kaludercic

[tarsius]

I am a little sad throwing the 644,050 Melpa downloads statistic away. ☹️

[phikal]

Just to be sure, you don't intend to remove the git-modes from MELPA, right? I don't think enough people use NonGNU ELPA yet to legitimize moves like that.

[tarsius]

No, I am gonna add git-modes, replacing the three separate packages.

[tarsius]

For a moment I though my mind was going...

I remembered we had talked about this somewhere but couldn't find anything. After digging around in the Melpa issue tracker and emacs-devel for quite some time, I finally realized it must have been here. Piuuu oO

I'll try to do it soon, probably today.