Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Packages created from repos on the Emacsmirror #1036

Closed
4 of 25 tasks
tarsius opened this issue Sep 15, 2013 · 10 comments
Closed
4 of 25 tasks

Packages created from repos on the Emacsmirror #1036

tarsius opened this issue Sep 15, 2013 · 10 comments

Comments

@tarsius
Copy link
Member

tarsius commented Sep 15, 2013

I asked @purcell elsewhere what packages were created from repositories an the Emacsmirror and then looked into how popular these packages are and how they get into the Emacsmirror:

DONE removed since in GNU Elpa

  • csv-mode
  • sml-mode

DONE get from new upstream

  • ssh-config-mode

DONE part of bigger repository

The Emacsmirror's basic unit is the repository. It cannot split that up into individual packages like Melpa does.

  • shimbun (w3m)

TODO no longer updated and popular

Contact upstream and/or add to Emacsorphanage.

  • crontab-mode (2132)
  • session (2687)
  • smarty-mode (2039)

HOLD no longer updated and obscure

  • dedicated (87)
  • keydef (71)
  • log4j-mode (181)
  • pager (61)

TODO currently not updated from plain files and popular

Contact upstream and/or add to Emacsorphanage.
Importing from plain files is currently broken on the Emacsmirror.
This will eventually be fixed but not very soon.

  • diminish (7183)
  • hl-sexp (1970)
  • mwe-log-commands (2372)
  • pointback (2039)
  • textile-mode (2144)

HOLD currently not updated from plain files and obscure

Importing from plain files is currently broken on the Emacsmirror.
This will eventually be fixed but not very soon.

  • edit-list (107)
  • escreen (162)
  • fm (110)
  • fold-dwim (328)
  • osx-plist (152)
  • parenface (242)
  • psvn (205)
  • revive (256)
  • xterm-frobs (46)

Edit: added missing information
Edit 20140627: mark some things as done
Edit 20141104: note that plain file import is broken

@tarsius
Copy link
Member Author

tarsius commented Sep 15, 2013

I created the Emacsorphanage a while ago but the baby hatch got never used (not really surprising as I have not announced it anywhere).

The idea is that it would be used for packages that are popular and are no longer maintained. Authors could also move their packages there if they are looking for a new maintainer (or have me create a fork).

@purcell, @milkypostman are you interested in becoming guardians, we could then proxy maintain some of the more popular packages (I don't actually plan to do any development, just fix serious issues when the get reported). The Emacsmirror is not the right place to do that and using our private accounts also has its drawbacks. The orphanage could also be used to do clean up necessary before inclusion into Melpa.

Edit: Also note the nice organisation image and how it corresponds with those of the Emacsmirror and Emacsattic :-)

@purcell
Copy link
Member

purcell commented Sep 15, 2013

Hey Jonas, thanks so much for going through that list. I've corrected ssh-config-mode, for starters.

Regarding the packages also in GNU ELPA, it probably does make sense to remove them, though it's partly a question of whether the authors release new packages regularly as they make ongoing changes.

I like the idea of the emacsorphanage: all this stuff should really be in VC repositories which can be contributed to. After all, this is 2013. The orphanage should of course be a last resort, but yes, I'd be happy to be a member of the org and occasionally field requests. We've never wanted to directly host upstream code next to MELPA, so this would provide a helpful separation.

@tarsius
Copy link
Member Author

tarsius commented Sep 15, 2013

Hey Jonas, thanks so much for going through that list. I've corrected ssh-config-mode, for starters.

Glad I could help. The same occasionally happens the other way around, when I notice that some package I mirror from the Emacswiki is built from elsewhere by Melpa.

Regarding the packages also in GNU ELPA, it probably does make sense to remove them, though it's partly a question of whether the authors release new packages regularly as they make ongoing changes.

I am mirroring these packages from GNU Elpa! So unless you can find the real upstream these packages should be dropped from Melpa. (I possibly used to mirror some upstream. There are various reasons why I might have switched from that to GNU Elpa. I cannot find any notes on that.)

We've never wanted to directly host upstream code next to MELPA, so this would provide a helpful separation.

Same here with the Emacsmirror. Melpa and the Emacsmirror having some sort of Tochergesellschaft (en: subsidiary) will hopefully encourage further collaboration.

Speaking of which; how is it going with Marmalade and El-get? The respective threads on this issue tracker seem a bit dormant.

It would probably be a good idea to have a shared mailing list for Melpa, Marmalade, El-get, Emacsmirror, and related projects. A long time ago, when package.el was in its infancy, I did set up such a mailing list on Savannah: https://lists.nongnu.org/mailman/listinfo/emacs-pms-dev. Back then I contacted people involved with such projects but unfortunately the interest was minimal.

The mailing list still exists and could be reactivated. It would also be no problem to create a new list, if we want another name. I have already asked the Savannah maintainers about this. (I contacted them because I am also considering moving the Magit list there).

Off topic:

After all, this is 2013.

Tell Drew Adams about it :-) Icicles seems like a really nice package but the last time I was giving it a try I drowned in a see of ifdefs. Its a real shame how much time he wastes maintaining compatibility with ancient Emacsen and how his refusal to use a vc (and instead having all branches in... one branch sprinkled with ifdefs) makes it impossible for me, and I suspect many others, to contribute to, or even just use his code.

@tarsius
Copy link
Member Author

tarsius commented Sep 15, 2013

Staying off-topic:

I actually think you should contact Drew privately and explain to him why branches and version control / git in general are a good idea. I tried doing so years ago and we had a constructive conversation but I ultimately failed to explain why leaning a vc would be a huge time safer for him and would make his code more accessible to others.

You are very good at explaining stuff, so could you please explain it to him when you find the time. He has some cool stuff sitting on the wiki and making it available in a more accessible way would be a great service to the community. I am already doing that to some extend by making his code available on the Emacsmirror, but it just ain't the same.

@tarsius
Copy link
Member Author

tarsius commented Sep 15, 2013

Made you an owner of the orphanage. You might wanna make your membership public for advertisement purposes :-)

purcell added a commit that referenced this issue Sep 16, 2013
These packages are just GNU ELPA mirrors via Emacsmirror...

See #1036
@purcell
Copy link
Member

purcell commented Sep 16, 2013

I am mirroring these packages from GNU Elpa! So unless you can find the real upstream these packages should be dropped from Melpa. (I possibly used to mirror some upstream. There are various reasons why I might have switched from that to GNU Elpa. I cannot find any notes on that.)

Thanks, removed.

Speaking of which; how is it going with Marmalade and El-get? The respective threads on this issue tracker seem a bit dormant.

Yeah, we're just pushing ahead with trying to provide a useful service. There are apparently some fundamental differences of opinion between the MELPA and Marmalade maintainers. Not sure about el-get, but I know Dmitry was personally interested in moving in the direction of MELPA.

It would probably be a good idea to have a shared mailing list for Melpa, Marmalade, El-get, Emacsmirror, and related projects.

Maybe, but I'm currently wary of spending a lot of time debating stuff, so I wouldn't be in a hurry to get deeply involved. Donald & I have previously put in work to get consensus on packaging, and it didn't really get anywhere.

The mailing list still exists and could be reactivated. It would also be no problem to create a new list, if we want another name. I have already asked the Savannah maintainers about this. (I contacted them because I am also considering moving the Magit list there).

Yeah, that could be a reasonable first step.

After all, this is 2013.
Tell Drew Adams about it :-) Icicles seems like a really nice package but the last time I was giving it a try I drowned in a see of ifdefs. Its a real shame how much time he wastes maintaining compatibility with ancient Emacsen and how his refusal to use a vc (and instead having all branches in... one branch sprinkled with ifdefs) makes it impossible for me, and I suspect many others, to contribute to, or even just use his code.
Staying off-topic:

I actually think you should contact Drew privately and explain to him why branches and version control / git in general are a good idea. I tried doing so years ago and we had a constructive conversation but I ultimately failed to explain why leaning a vc would be a huge time safer for him and would make his code more accessible to others.

Yes, we've already had this discussion with Drew via email and failed to make much progress. I can kinda understand him sticking with what's working for him, even if I don't particularly like it. He at least agreed to start adding package dependency headers (though only with minimal "0" versions).

@milkypostman
Copy link
Member

Will close this. Because I am unclear on if this er relevant anymore. @tarsius please reopen if you feel this is still relevant.

@Silex
Copy link
Contributor

Silex commented Aug 29, 2017

I came here because crontab-mode does not exist anymore. What is the TL;DR; version about it? Should I copy it locally in my emacs config?

@purcell
Copy link
Member

purcell commented Aug 30, 2017

What is the TL;DR; version about it? Should I copy it locally in my emacs config?

There's no known current maintainer, or person able to assign copyright to the existing code. So probably yes.

@Silex
Copy link
Contributor

Silex commented Aug 30, 2017

Alright, thanks 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants